What's so RESTful about ASP.NET MVC?

Question

REST has been such a popular buzzword for the last couple of years (or so) and when ASP.NET MVC was 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 definitelly 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. 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.

Answer 1

This link might enlighten you in your quest ... well in short you can have Urls like you describe - at least with MVC 2.

Answer 2

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.

Answer 3

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.

Answer 4

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:

1. Passing a hidden input in an HTML form such as _method.
2. Using JavaScript to do the PUT or DELETE
3. 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.

Answer 5

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.