Question

So I see that MVC 2 now supports [HttpPut] and [HttpDelete] as well as [HttpGet] and [HttpPost], making it possible to do a full RESTful Web service using it.

I’ve been using the REST toolkit for WCF for a while and find it fairly powerful, but I’d be interested to find out what (if any) advantages there are using the MVC 2 approach.

Links, war stories, or even pure hear-say are welcome.

Answer 1

I’m pretty sure ASP.NET MVC has supported all the HTTP verbs since the beginning. At least the HttpVerb Enumeration has had them from the beginning. The only thing that’s new in V2 is that they are attributes.

// V1
[AcceptVerbs( HttpVerbs.Delete )]

// V2
[HttpDelete]

Six of one, half a dozen of the other. As to whether you want to expose functionality through WCF or ASP.NET MVC, it would come down to how you think of your application.

• If you think of it as a thick client app that just happens to be written in JavaScript and calls out to restful services for data (then formats it client side) then WCF would feel like a more correct solution (even though you could do it using either).

• However if you think of your application as a server app that returns content in some form or another for consumption, then using a RESTful API for your actions would make more sense. Your actions would return fully formatted content that would be displayed in the browser without a need for further processing. You could return formatted content (HTML or otherwise) from a web service, but that would somehow feel wrong.

At least that kind of distinction makes sense in my head =). You may also be interested in Phil Haack’s post on How a Method Becomes an Action.

---

There’s now another option, Web API. ScottGu has a brief introduction in his blog and there’s an interesting blog post discussing creating APIs using the Web API vs controllers here.