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.

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.

In my last post we added functionality to the web service to accept incoming representations in the form of a PUT request. At the end of that post I admitted I hadn’t implemented the functionality to accept an incoming XHTML representation. The problem was with parsing a string of XHTML using .Net’s built in XML parsers. Loading XHTML straight into an XmlReader causes either an, “An error has occurred while opening external DTD” or a, “Reference to undeclared entity” exception.

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.

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.

Our web service has changed over this series of posts until now it supports a more complex resource… but its still a read only web service. In this post we’ll add support for the DELETE HTTP verb. This should be the simplest of the remaining verbs to implement… but it does highlight some more issues to be dealt with.

In this series of posts we have been using a simple GUIDs resource to build a basic framework for a RESTful web service. As we start to explore the other HTTP Actions we need a more complex resource. I decided to create a Products resource that supports the listing, creation, updating and deletion of products. It will also support “child” representations for each category of product.

In my previous posts on this subject I have gradually developed a web service that handles multiple representations and returns appropriate HTTP Response Codes. I’m now moving on to what Roy Fielding described as the Uniform Interface.

A web service exposes a uniform interface if all its resources can be accessed by the same small set of well known methods (or a subset of those methods). In HTTP, the uniform interface contains methods (or verbs) such as GET, PUT, POST, DELETE, HEAD etc. In RESTful Web Services, Richardson and Ruby explain HTTP’s uniform interface as:

All interaction between clients and resources is mediated through a few basic HTTP methods. Any resource will expose some or all of these methods, and a method does the same thing on every resource that supports it.

The benefit of this approach is that clients can be developed to run against many different applications without the developers having to learn a new interface. Imagine if the world wide web was made up of web sites that had each developed their own interface… web browsers would have to be coded to deal with each site individually! If that had been the case, the web would not be the huge success it is now. However, that is the approach being taken by SOAP based web services.