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:
September 27, 2008 00:18 by Admin
My View of a RESTful Web Service
Early in 2008 I attended a presentation by Tim Ewald in which he introduced his take on RESTful web services. I’d come across them before, but he provided the momentum for me to look more closely at them. I spent some time reading around the idea and bought the bible on the subject, RESTful Web Services.