50

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!

Robert Koritnik
  • 103,639
  • 52
  • 277
  • 404
  • 2
    Hyperlinks cause a GET, and form submits a POST, so therefore using DELETE and PUT would be impossible through normal browser actions unless replacing them with something like AJAX. – Jess Sep 16 '10 at 21:12
  • @Andrew: I've stated the same in my question a few minutes ago. I agree. – Robert Koritnik Sep 16 '10 at 21:14
  • 1
    @Andrew, that's not necessarily true though, is it? I think you can specify that your form method can be GET also, right? – DaveDev Sep 16 '10 at 21:52
  • @DaveDev: Andrew is actually right. HTML element `FORM` defines `METHOD` attribute with only two valid values: `GET` and `POST`. Nothing else. So `DELETE` or `PUT` are not supported. Not by HTML specification. – Robert Koritnik Sep 16 '10 at 22:02
  • is post & delete an ASP.NET MVC limitation? – DaveDev Sep 16 '10 at 22:14
  • 1
    @DaveDev, no it's browsers limitation. – Darin Dimitrov Sep 16 '10 at 22:17
  • @DaveDev: No. It doesn't have anything to do with Asp.net MVC. Fully RESTful application must use them. Meaning: in order to create a fully RESTful Asp.net MVC application you would have to use Ajax on the client side. Browser alone (or better said HTML alone) won't be able to use RESTful server-side application... – Robert Koritnik Sep 16 '10 at 22:19
  • @Robert, I'm not disputing the point he made about DELETE & PUT being impossible through normal browser interaction, it was more to question the assertion that a form submits a POST. I ask because I can specify that a form submit a GET, and I'm wondering if because it's a form submission, is it a real 'GET'? – DaveDev Sep 16 '10 at 22:21
  • 2
    @Robert & @Darin, so if if it's a browser limitation, you can't really blame ASP.NET MVC for having to submit DELETE & PUT requests asynchronously? – DaveDev Sep 16 '10 at 22:23
  • You can tunnel `DELETE` and `PUT` through `POST`, as Rails did. I explained it as an answer below as the comment space is too small. – Muhammad Alkarouri Sep 17 '10 at 12:23
  • @abatishchev: Styling? BTW: As the originator of this term says (JJGarrett), Ajax shouldn't be written in ALL CAPS. But only capitalised. I'm not sure about Asp.net, so I'll leave that as you've changed them (to my opinion these kind of changes are ridiculous). – Robert Koritnik Sep 17 '10 at 17:29
  • @Robert: Thanks for quoting JJGarrett, I'll mind that. And be sure, ASP.NET should be ALL CAPS :) – abatishchev Sep 19 '10 at 07:55

7 Answers7

27

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.

Martin
  • 11,031
  • 8
  • 50
  • 77
Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
  • I was just editing my question when you posted your answer. Yes Fully RESTful MVC app is possible. With an additional observation about Ajax taht I pointed out. – Robert Koritnik Sep 16 '10 at 21:12
  • 2
    Ajax is a client scripting technology. It has nothing to do with REST. 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. – Darin Dimitrov Sep 16 '10 at 21:14
  • 1
    That's completely true. But since Asp.net MVC is a web framework whose views are going to be consumed by browsers, Ajax should still be mentioned. But you're right. Asp.net MVC can be made completely RESTful. – Robert Koritnik Sep 16 '10 at 21:26
16

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.

Wyatt Barnett
  • 15,573
  • 3
  • 34
  • 53
14

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.

pc1oad1etter
  • 8,549
  • 10
  • 49
  • 64
  • 3
    This is by far the best response to this question. – rojoca Sep 20 '10 at 23:51
  • There is, however, a URI style that makes an API _unrestful_. Specifically, if the URI doesn't correspond to a resource. – Muhammad Alkarouri Jun 28 '11 at 01:08
  • I would say that's more of a characteristic of what gets identified by the URI than the "style" of it -- I am alluding to the pattern of characters in the URI when I say style. But sure, they should correspond to resources. – pc1oad1etter Jun 30 '11 at 18:55
  • 1
    You are right of course if the URI "style" means only the characters. My interpretation was - similar to the addresses above (`/x/create/1`, `/x/update/1`, ...) - the URI itself carries some semantic connotations in such a way that you are expected to calculate one URI from the other, rather than use HTTP verbs and encode related actions as URIs embedded in the representation (the hypermedia constraint). In the latter case, the system is unrestful. – Muhammad Alkarouri Jul 02 '11 at 15:07
6

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

AxelEckenberger
  • 16,628
  • 3
  • 48
  • 70
  • I'm not saying that having RESTful execution isn't possible with MVC (**this was possible in 1.0 as well** you just didn't have the shortcut attributes), I'm just saying that the way they present the framework has very little to do with REST. And also PUT and DELETE verbs can only be done with Ajax FYI meaning that only a great usability application can be truly RESTful. – Robert Koritnik Sep 16 '10 at 21:09
  • 2
    Well it is really about possibilities and design ... MVC is a new more structured concept to web development that tries to make the life of the developer a bit easier, and at the same time offer him more possibilities in what he can achieve. So as long as it supports RESTful URLs it, IMHO, can be considered RESTful - even if the marketing and the simple samples do not show this quality immediately. – AxelEckenberger Sep 16 '10 at 21:16
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.

Muhammad Alkarouri
  • 23,884
  • 19
  • 66
  • 101
  • **Ad1**: That's not RESTful. POST is not idempotent... Second one is. And only Javascript powered clients can actually use fully RESTful server applications. That's the outcome of my question. – Robert Koritnik Sep 17 '10 at 17:21
  • @Robert: (1) is quite RESTful even though POST is not idempotent. REST is not about using the four methods, [as a comment by Roy Fielding, the inventor of REST, shows](http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-730). My PhD topic is largely about extending REST, so I know. Also, see my comment [here](http://www.reddit.com/r/programming/comments/cdnpb/the_reason_behind_the_halfrest_design_pattern/c0rvqus). – Muhammad Alkarouri Sep 17 '10 at 17:56
2

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.

Josh Gallagher
  • 5,211
  • 2
  • 33
  • 60
1

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

Robert Koritnik
  • 103,639
  • 52
  • 277
  • 404
  • **AD1**: No problem. Still applies as long as you post an array of particular entities. Server side should detect that and do the necessary. **AD2**: Use query variables `www.example.com/products?latest`. **AD3**: Same applies. Query variables: `www.example.com/products?page=2&size=15`. Add any others as well ie. filter crieria or sort property – Robert Koritnik Oct 10 '13 at 10:56
  • ASP.NET Web API OData controllers would address issues two and three pretty easily out of the box too. Very powerful. – Josh Gallagher Aug 22 '14 at 22:44