/controller/action/id
or
/controller/id/action
Which is more common? Which is preferable and why?
Are there any pro's / con's of using one or the other?
Edit:
Or, perhaps to think of this question in a different way, why do most MVC frameworks (ASP.Net MVC, Grails, Spring MVC) default to the /controller/action/id URL pattern? Is there some advantage to this?
Neither of these are RESTful. There should not be verbs/actions in a URL. Those are confined to the HTTP method for good reason (so that clients can interact with your service without knowing anything specific about it).
If you can not do anything except GET and POST, use POST to send an action parameter to /controller/id
Asp.Net MVC uses /controller/action/id. So that is what you'll most often see in that environment. I do not see any technical benefits but simply going with a common pattern can make things easier to understand.
I definitely prefer /controller/action/id. This feels to me more like it is identifying a resource (a noun) rather than identifying an action on that noun (a verb).
In addition to the exact URL to the resource, you need to consider how you are mapping the HTTP verbs. In my experience, we have shuffled the URL around based on what made most sense when combined with the verbs. That said, we also have a couple places we broke the canonical approach for convenience sake (for example, exposing a certain delete action with a GET so that users could perform the action via a browser).
Also take a look at this discussion for more.
REST URL structure advice
Related
I am wondering if there is any written standard on the naming of controllers in asp.net core/mvc/api?
I am not really finding anything.
Thanks
The standard is implied with REST Api Design standard.
That means if you are providing a REST point for the handling of multiple countries you would create a CountriesController which would be routed to by asp from https://localhost:443/countries/.
The convention is name it according to the route it should have, which in case of an API should be countries to conform to REST principles. However, that convention is based on utilizing a default route which simply maps whatever comes before Controller as part of the path. With attribute routing, or even simply just custom standard routing, you can make the route whatever you want, which then means that the controller could be named whatever you want, as it's no longer being utilized directly as part of the route.
Long and short, CountriesController is probably better, since it aligns better to the route it should have, but ultimately, there's no hard and fast rule here. As with most questions like this, the only answer is the one that makes the most sense for you, your team, and your application, which none of us here can dictate for you.
I'm trying to build some RESTful services using spray. I've figured out how to build the directives I need. But the issue I'm having is how to reliable generate URLs back to the "resources" I'm working with. Note I use the term "resources" here as it is used for RESTful APIs (i.e. the server side objects one refers to through the API).
I've looked through the documentation and I haven't found any reference for this except mention of "Resources" in the Java sense (i.e. data files in the classpath).
For sure I can build a directive that maps "/items/127" to a resource on the server side. But what I don't see how to do (at least in a safe and automatic way) in Spray is how to generate such a URL given the server-side resource. I'm looking for something similar to url_for from the Flask framework.
For now, I'm writing functions to do this. But, of course, they are fragile because they aren't DRY (i.e. they don't use any knowledge of Spray routing in generating the URLS).
Am I missing something?
What you're asking for is known as reverse routing. As #iwein said, there's no direct support for reverse routing in Spray. You can confirm this from Matthias in this thread. There is an open ticket for this issue.
However, there is an approach, based on the PathMatcher that Marcel Mojzis open sourced which you can find here.
I have a need for this as well, but I'm going to get by with a "known pattern" approach until Spray (or akka-http) comes up with its own solution to this issue. Essentially, I have an object that knows how to generate the URL for certain patterns of things. Each pattern is a function and clients of the object have to ask for the url by one of the function names. Not ideal, but very simple and effective until akka-http provides a more generic solution.
I don't think that Spray has an equivalent of url_for. I don't think it would make sense in the context of Spray, because in Spray you're not annotating functions with urls that map to them, but you're creating routes that deserialize requests and eventually map them to functions.
As such there is no easy way to generate an example url from the name of a function.
REST has been such a popular buzzword for the last couple of years (or so) and when ASP.NET MVC rolled out, everyone was relating REST with ASP.NET MVC. I also fell for the buzz and from the lack of my knowledge, my understanding of REST was simply just:
REST = SEO/User friendly URLs
But it's so much more. And the more I learn about REST the less I relate ASP.NET MVC with it. It is of course much closer to REST than WebForms. So the truth is actually quite the opposite:
REST ≠ SEO/User friendly URLs
And having your default route defined as controller/action/id is definitely not RESTful.
Let me explain my problem with this comprehension.
If ASP.NET MVC was RESTful, we wouldn't have default route defined as:
controller/action/id
but rather
resources/id /* that would have to use HTTP methods GET/PUT/POST/DELETE */
So instead of having (also providing HTTP method with request path):
/product/index/1 /* GET */
/product/create /* POST */
/product/delete/1 /* POST */
/product/update/1 /* POST */
it should be (HTTP method provided here as well)
/products/1 /* GET */
/products /* POST */
/products/1 /* DELETE */
/products/1 /* PUT */
Now that would be RESTful. The good thing is that this is actually possible. And if you'd make it fully RESTful it would also mean that you'd have to use Ajax because PUT and DELETE methods can not be done with browser-only requests (this is not completely true1). So modern Ajax applications can actually be completely RESTful.
Ajax is client technology and doesn't really have anything to do with ASP.NET MVC. Fact is that ASP.NET MVC can be done as a fully RESTful application. The means of achieving it (Ajax) is not important. (thanks to Darin Dimitrov)
The main question
Why do we consider ASP.NET MVC as a RESTful framework especially relating its URL routing to it? Why didn't they define default URL route to enforce RESTfulness? I'm not looking for argumentative answers but those that actually answer the question - how did this relation come into life... Maybe I'm still not wise enough and still take this as the lack of my knowledge about both.
1Updated info
Actually you don't have to use Ajax to implement fully RESTful architecture. Asp.net MVC supports (since version 2) HTTP method overriding, meaning you can issue PUT or DELETE methods using browser forms. All you have to do is add an additional hidden field like:
<input type="hidden" name="X-HTTP-Method-Override" value="DELETE" />
Asp.net MVC framework will be able to understand such POST request as a DELETE request and HttpDeleteAttribute action method selector will also understand it as a delete request. HTTP Method overriding FTW!
There's nothing preventing you from having routes like resource/id with HTTP methods GET/PUT/POST/DELETE in ASP.NET MVC. It's not the default routes setup but you can do it.
EDIT (MLaritz - Adding Darin's comment):
ASP.NET MVC is a server side technology allowing you to expose RESTful urls. The way they are consumed doesn't matter. You asked about why ASP.NET MVC is considered RESTFul technology and the answer is because you can easily expose RESTFul urls for consumption, it's as simple as that.
I think alot of the buzz had more to do with how un-RESTful the .NET web stack was before MVC and how much easier MVC made it to build RESTful apps on the .NET platform than any particularly RESTful capabilities ASP.NET MVC has.
There is no URI style that makes an API restful.
You asked, "Why do we consider ASP.NET MVC as a RESTful framework especially relating its URL routing to it? "
Because REST is misunderstood to be about URLs instead of about resources, a standard interface, and hypermedia.
This link might enlighten you in your quest ... well in short you can have Urls like you describe - at least with MVC 2.
I just thought to contribute to the REST discussion about the use of PUT and DELETE.
In general in REST and other RESTful frameworks, the issue of PUT and DELETE is not solved by making URLs such as resource/create or resource/delete. Rather, the verb is tunnelled through POST by:
Passing a hidden input in an HTML form such as _method.
Using JavaScript to do the PUT or DELETE
To overcome some firewalls, you may need to use the HTTP X-HTTP-Method-Override header.
This is a general solution for the issue of HTTP methods.
I am not informed about ASP.Net to say why they didn't take that way, but a URL such as /product/delete/1 does not provide a RESTful resource.
Edit: A bit of clarification about what is REST seems to be necessary. From the horse's mouth:
A REST API should not contain any changes to the communication protocols aside from filling-out or fixing the details of underspecified bits of standard protocols, such as HTTP’s PATCH method or Link header field. Workarounds for broken implementations (such as those browsers stupid enough to believe that HTML defines HTTP’s method set) should be defined separately, or at least in appendices, with an expectation that the workaround will eventually be obsolete. [Failure here implies that the resource interfaces are object-specific, not generic.]
Emphasis mine. REST is not defined as using the four HTTP methods. It is not even defined as using HTTP. It needs a communication protocol with ability to follow hyperlinks. And it uses that protocol, with suitable definitions added without violating the protocol.
In the case of HTTP, using workarounds for browsers that do not implement PUT and DELETE is explicitly allowed. The Rails method in point 1 clearly does that.
This question is slightly dated, and the answer right now (2014-08) would be this: ASP.NET MVC allows RESTful URL schemes but isn't designed such that this is the default. Instead the pit of success with ASP.NET MVC is a more traditional Controller+Action style of MVC.
The ASP.NET way of writing RESTful services now would be ASP.NET Web API. This makes it even easier to create a RESTful URL scheme by use of method naming conventions that match the HTTP verbs.
Note that this answer will be out of date once what is currently called ASP.NET vNext is out, in which Web API and MVC are rolled into one.
Project Manager : "Let's develop our new project fully RESTful !!!"
Other programmers shout : "YAyyyyyy!!!"
Few weeks later in development stage : "Sir, we need to let the client to be able to update multiple rows at the same time, therefore we need to do a workaround"
"Sir, I need to get only the latest invoice"
"Sir, I must pass the paging numbers and size!"
bummer. why don't we all go back to XML RPC
I'm a little late to the party, but I'm trying to wrap my brain around how REST is supposed to work, both in general and in Ruby on Rails. I've read a bunch of articles online about this already, but still don't feel like I'm getting the big picture.
REST as I understand it, is a series of aspirational statements, with the net result at the bottom being that URLs should contain all the information necessary to handle a request, and gets should not be able to change the state on the server, and a bunch of other concrete guidelines.
As I understand it, REST in Rails is based around CRUD, which is to say, every model has a create, read, update and a delete action. Each of these actions is accessed through a similar set of URLs, generated by mapping a resource in the routes. So a login URL is creating a user session, so the URL would look like example.com/session/new with a POST, and logout would be example.com/session/destroy with a POST.
What exactly is the benefit of standardizing URLs in this fashion? It strikes me as optimizing for machine readability at the expense of human readability. I know that you could then remap in the routes file example.com/login to example.com/session/new but that is just one more step for no apparent gain to me.
Is it considered really bad practice to develop a website that uses traditional routes now?
Furthermore, each of these CRUD actions should be able to respond to requests with whatever type of response the request is looking for. So the same link to, say, example.com/tasks could also be called at example.com/tasks.xml to get an xml representation of the result, or example.com/tasks.json for a json representation.
Is this to say that a RESTful API would just be the usual links on the site but with xml appended? It strikes me as very strange and awkward that a web API would behave in this way, but this seems to be what's implied by everything I've read. I'm more used to seeing an API that has links like example.com/api/tasks to get the list of tasks. What exactly is the advantage of this approach?
Rest provides another chunk of "convention over configuration." For a widely used, limited set of common problems (crud actions against the models as a whole), rest is very useful as an application development convention.
What exactly is the benefit of
standardizing URLs in this fashion?
Programmer efficiency. Less to think about; enables more time to be spent on harder problems, etc. Better maintainability. Easier testing. Etc.
Is it considered really bad practice
to develop a website that uses
traditional routes now?
Yes, for crud actions that are interacting with an entire record of the model.
Furthermore, each of these CRUD
actions should be able to respond to
requests with whatever type of
response the request is looking for.
So the same link to, say,
example.com/tasks could also be called
at example.com/tasks.xml to get an xml
representation of the result, or
example.com/tasks.json for a json
representation.
Is this to say that a RESTful API
would just be the usual links on the
site but with xml appended?
Yes, if your api fits the rest model. I think the big issue is authentication. If you want your api to be stateless, then you'll probably need to include authentication with each call. At that point, if you don't want to use HTTP level authentication, you'd need to decide how to include the credentials.
I've been toying with the SimplyRestfulRouting assembly that comes with the MvcContrib extras, and for the most part I really like that it quickly sets up my routes and leaves me with a good convention to follow in my controllers. However, I'm still trying to wrap my head around REST as it applies to rich internet applications and occasionally feel pigeon holed when I need to do something that falls outside the scope of those 8 or 9 default routes. [Edit: By "pigeon holed", I simply mean I feel like I'm dirtying up the application when I have to create a controller action that is outside the definition of the default "restful routes".]
I heard a comment from a REST proponent in which he stated his opinion that the MVC framework is inherently RESTful, and it got me thinking a bit more about what libraries like the MvcContrib SimplyRestfulRouting are actually buying me.
Not having read a lot about the concrete pricinples of REST, I'm looking for input as to what benefits might come from enforcing such a thing in the context of a forms-over-data, RIA. And with regards to AJAX, how does a RESTful architecture affect my client interaction?
It's likely I'm misunderstanding the use of REST in this context, and would appreciate some StackOverflow mojo to get my head on straight.
The main benefit I can see in enforcing RESTful routes -- regardless of the framework used -- is consistency. You'll always be able to know how the API will work for any resource, which will in effect give you a self-documenting API.
It also provides a wonderful constraint while architecting the application. Rather than having an API with a blank slate that could get complicated very quickly, constraining the routes to the basics will give you guidance as to which resources you'll need to create.
For more of the basic principles surrounding REST, I'd recommend reading this thread.
Being RESTful is more than just having clean URLs.
At an architectural level, REST is about organizing your application functionality in terms of resources, and exposing a fixed and uniform set of CRUD operations on them (e.g. HTTP POST/GET/PUT/DELETE methods). This is known as Resource Oriented Architecture.
In contrast, with Service Oriented Architecture you typically organize application functionality in terms of processes or components, and expose non-uniform, application specific methods on them (e.g. via SOAP).
Note, you can have clean URLs but still end up following non-RESTful SOA design principles.
UPDATE: Sorry, didn't really answer the question, got hung up on use of "RESTful" terminology. If you're just talking about the benefits of clean URLs (REST/SOA argument aside), the typical argument is better SEO optimization and user-friendliness (user can better make sense of and modify URLs).
the advantage is that if you have some adress and from that adress you getting something, then you can call that adress from anywhere you want in you code, and you will get exactly same thing :)
and in concrete example, if you have route that can return some html full with data(user control for example), then you can call it from ajax, from your desktop application or even from your web service...it is very powerfull because you WILL have some functionality repeated over your application...and because some html that you getting from that restful service giving you exactly one view with exactly one functionality, you can call it dynamically from dialog or from page or from your desktop application or from anywhere...
and when you add to this that you can call this adress with parameters, exactly like some method, you can now see how powerfull this can be in creating dynamic pages and web sites/systems
hope this helps