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
Related
I am reading about how should I design my rest API endpoint for different users. while searching I found a concept of content negotiation on StackOverflow, where someone suggests using different media types like this
application/vnd.example.contactsummary+json and
application/vnd.example.profilesummary+json
See the accepted answer here for more clarification.
Now I am a little bit confused and I didn't found any answer to questions that arise in my mind.
If the endpoint is the same. does it mean that we have the same action method in a controller to handle two different requests e.g for admin and user?
If we use different action methods then how should we create routes on the basis of headers in .net? as I found the solution of PHP framework here
If we're creating different actions then why not use different routes e.g /admin/courses and /courses, what my understanding is that we use the same route for different users because we want a single get/post/put or patch method for one resource to keep API consumption easy
And if we're using different actions for the same route. should we create them in the different controller for the sake of Separation of concerns?
I'm newbie in angular so i have two questions on AngularJS routing. Deeply sorry if this has been answered. tried a brief search, didnt find exact match.
I get the idea of SPA, the cost of asp.net server round trip,
however, what's a valid real world scenario that make best use of
both server side routing and client side routing together? or simply
give up the asp.net mvc routing at all?
If partial routing rules
defined on both side, isn't it a bit messy?
well, that depends on what you need I saw some people doing a mix of routes between angular and MVC, you can take a look to he boilerplate and hot towel projects for asp.net and angular combo take them as reference, both are like starter kits.
In my personal opinion (and this is subjective), I prefer to use a RESTFul architecture / SPA let angular do the routing and have web API or service stack as a middleware very much like the mean.js approach for me it's a cleaner and more natural for a SPA application.
take a look to this article that talks about rest API and some best practices.
I don't know if there's a perfect answer since it all depends on the project you're working on and the preferences of the dev team. I personally like keeping some of the MVC concepts (mvc views, routing, etc.) and just using angular for a given page's functionality. I don't make use of the angular routing at all. Obviously it would be a different story if you were trying to create a full SPA.
But I find that in a lot of cases (especially if working on an existing app written in MVC) you can introduce bets and pieces of angular without taking it all the way. If you're trying to get rid of page redirects entirely and want a full SPA experience then you should probably use a service approach instead as already suggested (if you want to stay with the Microsoft stack, Web API is a good option).
/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
We have recently shifted to asp.net mvc, but we still need to support some legacy urls. What is the best way to handle this situation. Is it Application_PreRequestHandlerExecute() event in global.asax, that I need to use or is there any better way?
You can use the URL Rewrite module for IIS7. Scott Hanselman has a good post on using URL rewrite to to handle legacy URLs here.
Another option, I believe you can simply add a route that matches your old url syntax.
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