In an ASP.NET MVC 4 website I'm using Web API to return JSON-formatted resources including links for authorized actions (e.g., DELETE). To create these links I'm using the GetUrlHelper() extension method on the HttpRequestMessage...
_httpRequest.GetUrlHelper().Link( routeName, routeValues );
My concern is that the string returned from Link() is a fully qualified URL (it includes the https://example.com/...) when all I think I need is the relative URL (just the /my/resource). Currently, I've got a server problem where our production environment is adding http when it should be https, which doesn't work. I can fix that separately, but it raises the question, should I just supply a relative URL? And if so, is there a better way of getting a relative URL than trimming off the root part of the UrlHelper.Link()-generated URL?
Edit:
After consulting Richardson's & Ruby's meritorious RESTful Web Services, I believe more firmly that a relative URL is wholly appropriate here.
Does the PathAndQuery on Uri help you?
Example: (new Uri(_httpRequest.GetUrlHelper().Link("DefaultApi", new { controller = "Values", p1="abc" }))).PathAndQuery...this would give you like /my/resource?p1=abc
Related
I am new in Yii Framework. I am doing one small correction in Yii framework web app. Their third party Fax(Fax.de) API providers change something, I am trying to change the code, but I couldn't get the right file.
If the URL is www.example.com/paymentoption. What controller will work and where can I get Route folder?
Please help me...
in yii there is no route folder or file.
From Url you can simply find the controller named paymentoption. and in that you can find the method actionIndex which is called by Default
From documentation:
Routing involves two steps:
the incoming request is parsed into a route and the associated query
parameters; a controller action corresponding to the parsed route is
created to handle the request. When using the default URL format,
parsing a request into a route is as simple as getting the value of a
GET query parameter named r.
When using the pretty URL format, the URL manager will examine the
registered URL rules to find matching one that can resolve the request
into a route. If such a rule cannot be found, a
yii\web\NotFoundHttpException exception will be thrown.
Once the request is parsed into a route, it is time to create the
controller action identified by the route. The route is broken down
into multiple parts by the slashes in it. For example, site/index will
be broken into site and index. Each part is an ID which may refer to a
module, a controller or an action.
In this case, the link: www.example.com/paymentoption will use the controller PaymentoptionController and actionIndex, or it could be a module.
I recommend reading the documentation on the part of the Routing and Url manager: https://www.yiiframework.com/doc/guide/2.0/en/runtime-routing
Yii is a conventional based framework. That is, You should follow certain naming conventions to create your component.
For example. Your controller should be
SomenameController
Notice, above controller name has naming convention Controller adjoined to Somename
Here, You don't have folder to router, but controllers
//Get controller name
echo Yii::$app->controller->id
You can find a controller with that name in your controllers folder.
Umbraco: ver: 4.8
The page in Umbraco is setup with the link: mycontroller-myaction
I have no problem with this routing the controller/action in question. We're using the Node Factory to get the current node (umbraco.NodeFactory.Node.GetCurrent().Id) which is populated on the view (Razor). However, if I have my action setup to accept a parameter:
public ViewResult MyAction(int id) { }
Going to www.domain.com/mycontroller-myaction?id=1234
the querystring on EITHER the umbraco.library.RequestQueryString or the base Request object on ControllerBase does not contain the "id" querystring.
So to me, Umbraco is doing something with it and I don't see what. I don't know enough about Umbraco to know what I need to do, for Umbraco's route handling to ensure it passes on the querystring.
Anyone able to provide some insight?
Note: Circumventing Umbraco by not going to the route specified in Umbraco for the page as listed above, and instead going to domain.com/mycontroller/myaction?id=1234 works fine - more reason to know I don't know enough about what Umbraco is doing with querystrings.
Thanks,
This has to do with url rewriting:
Url rewriting .NET
Look at the docs, in page 10 and following.
I'm trying to achieve urls in the form of http://localhost:9294/users instead of http://localhost:9294/#/users
This seems possible according to the documentation but I haven't been able to get this working for "bookmarkable" urls.
To clarify, browsing directly to http://localhost:9294/users gives a 404 "Not found: /users"
You can turn on HTML5 History support in Spine like this:
Spine.Route.setup(history: true)
By passing the history: true argument to Spine.Route.setup() that will enable the fancy URLs without hash.
The documentation for this is actually buried a bit, but it's here (second to last section): http://spinejs.com/docs/routing
EDIT:
In order to have urls that can be navigated to directly, you will have to do this "server" side. For example, with Rails, you would have to build a way to take the parameter of the url (in this case "/users"), and pass it to Spine accordingly. Here is an excerpt from the Spine docs:
However, there are some things you need to be aware of when using the
History API. Firstly, every URL you send to navigate() needs to have a
real HTML representation. Although the browser won't request the new
URL at that point, it will be requested if the page is subsequently
reloaded. In other words you can't make up arbitrary URLs, like you
can with hash fragments; every URL passed to the API needs to exist.
One way of implementing this is with server side support.
When browsers request a URL (expecting a HTML response) you first make
sure on server-side that the endpoint exists and is valid. Then you
can just serve up the main application, which will read the URL,
invoking the appropriate routes. For example, let's say your user
navigates to http://example.com/users/1. On the server-side, you check
that the URL /users/1 is valid, and that the User record with an ID of
1 exists. Then you can go ahead and just serve up the JavaScript
application.
The caveat to this approach is that it doesn't give search engine
crawlers any real content. If you want your application to be
crawl-able, you'll have to detect crawler bot requests, and serve them
a 'parallel universe of content'. That is beyond the scope of this
documentation though.
It's definitely a good bit of effort to get this working properly, but it CAN be done. It's not possible to give you a specific answer without knowing the stack you're working with.
I used the following rewrites as explained in this article.
http://www.josscrowcroft.com/2012/code/htaccess-for-html5-history-pushstate-url-routing/
While investigating the Organization.svc in Dynamics CRM, I found that it is using URL redirect for changing the Organizations. That means for each Organization it simulate URL to access Organization.svc.
There is just one SVC file but multiple URLs to access it e.g. Organization Org1 will have URL http://CRMserver_name/Org1/XRMServices/2011/Organization.svc and Org2 will have http://CRMserver_name/Org2/XRMServices/2011/Organization.svc
I was wondering if there is any benefits for doing this as compare to passing input param to SVC. Please share your thoughts on the pros and cons for these two things.
I learned something new today. Pardon me if you know this already.
There are two different things –
URL routing - http://msdn.microsoft.com/en-us/library/ee358760.aspx
URL rewrite - http://msdn.microsoft.com/en-us/library/ms972974.aspx
URL routing is ultimate thing. It is totally virtual and no need to register routes in IIS. So now I know why Dynamics CRM is using it. Using routing client doesn’t need to specify Organization name for each method call of WCF service. While creating client object, URL itself gives that info. Client only needs to do this once and all methods are now aware of Organization name for particular WCF call.
This example can help get you started with URL routing for WCF - http://msdn.microsoft.com/en-us/library/ee662952.aspx
Hope this helps someone!
-Nilesh
My guess would be cleaner URLs and also it follows a sort of conventions for Dynamics CRM. As far as I can tell, URLs have always been in the format http://CRMserver_name/OrgName/...
I would like to know if there is some best practices about the root endpoint for a REST web service? I mean, should it be a short documentation about the usage of the API itself? Should it be an XML document describing all methods available? Should it only return "unknown method"?
The question is perfectly clear to me.
I think it should respond with 404. If there is no resource associated with the root path, then there is nothing to return.
If you feel that 404 is not helpful, then it would also be OK to return the URL of the documentation.
REST is supposed to be self describing so having the root show an error is poor design in my opinion.
I like the root to contain information that allows you to navigate the rest of the API.
So for example the root might contain a link to a list of product categories from which the API user can select a category and then a list of products etc.
A self describing API means less documentation to write and keep updated!!
NerdDinner.com1
The Sun Cloud API
Twitter
Paul Jame's article
MediaWiki's API2
1. NerdDinner uses WCF Data Services, which is a great way to correctly implement RESTful services. The reason I am point to that, and not WCF data services directly is because it is a public website and you can use it.
2. MediaWiki is not a great example because they are passing actions in the URI but it is technically a RESTful service and show's a lot of interesting ideas.
This question as asked is unclear. I would guess it means something like a directory that all API methods are under. For example, the root directory of the Flickr API would be http://api.flickr.com/services/rest/.
For an example of a project that accesses the Flickr API, see python-flickrapi
the rootend point of REST API is the the API defined for the first slash i.e "/" of the url after the dispatcher-servlet. It contains all the GET for the list of resources (mostly the get for all the database tables) this list further contains all the items and in single item there will be DELETE , PUT/PATCH and SELF get URL. Thus making the implementation of HATEOS.
For me, I just redirect to my frontend.
In node JS, use res.redirect("https://<<your frontend>>");