In this entry I would like to round up where we have got to so far with this web service. Over the last 13 posts we have developed a fairly functional web service that sticks pretty much to the ideas presented in Leonard Richardson and Sam Ruby’s book RESTful Web Services. It is developed using C# using the (currently Beta) MVC framework from Microsoft that extends the ASP.Net framework.

As an aside, I’ve also taken on board a comment from Stephan and moved some of the reusable classes into their own assembly.

More...

Now we can create a resource from an incoming XHTML representation, it is time to accept a representation of a new resource via an HTTP POST. This should be pretty much the same as accepting a new resource via an HTTP PUT.

So what is the difference between a PUT request and a POST request? A PUT request is made directly to the URI of the new resource, the client dictates the URI. A POST request is made to the URI of the new resource’s “parent” URI, the server decides on the full URI of new resource.

More...

So far, in this series of posts, we have got to the stage where we can retrieve different representations of a resource and we can delete a resource using either the HTTP verb DELETE or an overloaded POST. In this entry we will allow the client to PUT a resource onto the server.

More...

In my last post we introduced overloading of POST as a way to allow clients that can’t make PUT or DELETE requests. We handled the overloading within the controller… the ItemPost method looked for a query string parameter “_method” and if it found it, handed off processing to one of the other actions.

At the end of that post I admitted I wasn’t happy with the approach (as much the same code would be needed time and again throughout the web service) and I suggested some alternatives. As promised, I’ve thought about it and in this post I’ll present the solution I chose.

More...