November 15, 2008 00:57 by admin
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.
November 9, 2008 00:10 by admin
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.
November 7, 2008 01:45 by admin
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.
November 4, 2008 01:06 by admin
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.
October 22, 2008 23:58 by admin
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.
October 16, 2008 20:43 by admin
In this series of posts we have been using ASP.Net MVC to create a RESTful web service. In my last post I looked at returning the full set of standard HTTP Response codes. At the end of that post, the code was handling errors raised during the processing of an action. However, as I said then, that code would not catch all possible errors that are raised during the processing a request.
In this post I’ll look how our web service can handle those other errors instead of relying on the ASP.Net framework to handle them.
October 16, 2008 12:26 by admin
Roy Fielding’s original dissertation describes how a uniform interface is one of the key features of a REST architecture. When illustrating a uniform interface, many people describe the verbs that the interface exposes (e.g. in the case of HTTP these are GET, PUT, POST etc.). However, we should also consider the responses as part of that interface. One of the reasons HTTP fits the RESTful style so well, is that its limited and uniform interface includes the standard HTTP response codes.
In this post I’ll look how the web service we’ve been developing can return the full range of response codes available.
October 8, 2008 00:27 by admin
In the previous posts of this series I developed a RESTful web service capable of supplying multiple representations. For this post I wanted to add one more representation… “help.” This representation should allow anybody developing a client for the web service to discover and experiment with its capabilities.
October 2, 2008 00:10 by admin
This post continues my look at creating a RESTful web service using ASP.Net MVC Preview 5. The previous posts are
In this post I want to take the basic web service and add support for representations other than XHTML. I’m doing this because it is interesting and more legitimately, some representations might be more easily consumed by particular clients. I decided that my web service should support two extra representations: XML and JSON.
September 30, 2008 00:06 by admin
In this post I want to get a basic web service up and running. I’ll start off simple with a read only feature. Many database backed .Net applications use GUIDs as identifiers for their entities. Unfortunately, a number of client technologies cannot generate truly unique identifiers, for instance Flash based clients. Two possible solutions are: