What's so RESTful about ASP.NET MVC?

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 true¹). 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.

¹Updated 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:

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.

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!!!"

1. 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"

2. "Sir, I need to get only the latest invoice"

3. "Sir, I must pass the paging numbers and size!"

bummer. why don't we all go back to XML RPC