REST

What is REST?

REST is a model for creating services that embraces the model that the web uses. It is a model that is based on resources that are identified by a unique URI. Then, what you are intending to do with the resource is specified by a transport protocol verb. The model is formally not bound to HTTP but for all intents and purposes it currently is. The verbs generally used are: GET, PUT, DELETE and POST.

* GET – Retrieve the resource
* PUT – Update the resource
* DELETE – Delete the resource
* POST – Create the resource

There is some debate about whether you should also use PUT for creation and POST also gives a general catch-all for operations that don't really conform to CRUD (Create, Read, Update, Delete) operations.

Let's look at an example: we want to retrieve the list of products from the products corp. Order system. SOAP sends a message, using HTTP POST, to the order system endpoint (say, http://www.products.com/orderservice) with an action header of GetProducts. With REST we issue an HTTP GET to the URI http://www.products.com/orderservice/products. It is the verb that determines what we are trying to do and the URI that determines what we are trying to do it to. But more than this, REST based systems also return the URIs for the next valid set of operations depending on the context of where we are in the application protocol. So let's look at why this model doesn't suffer from the issues with SOAP detailed above.

HTTP scales

The fact that each resource has a different URL does not imply that they should all be on the same host. There is no need for a single "endpoint". This allows us, for example, to horizontally partition our data on to separate server farms where customers A-M hit one set of machines and customers N-Z hit another. In addition all read operations (namely those that do not alter state on the server) use HTTP GET. GET operations can be cached using the HTTP 1.1 caching directives which allows the service to offload traffic on to the general web infrastructure.
The application protocol is built into the message exchange

A fundamental part of REST is that the next set of valid operations is encoded in the response from the last. This means that as long as you only use actions from the last operation you will always perform a valid operation according to the application protocol.
The URI gives you context

The URI does not have to be a static thing but is inherently a data driven entity. Let's use an expense claim service: we can create a new expense claim passing a number of line items using
POST http://products.com/expenseclaim

This returns the next valid actions one of which could be submitting the expense claim to accounts. This action could be
POST http://products.com/expenseclaim/submission/456

The 456 in the URI is the identifier for the created expense claim. The crucial thing here is that the user can save the URI and then go home for the night. In the morning they simply submit to the URI and the context of where they were in the expense claim submission is maintained.
The payload is whatever makes sense

REST does services very often use XML as a payload but it does not bind you to it if some other format makes more sense. For example, if an AJAX application wants to use your service it makes more sense to return the data as JSON than XML; if the resource is an image then use an image.

Is REST perfect?

So if REST is so great should I always build my systems as REST based ones? Well some people would argue that but there are issues in REST.
No metadata

As may be apparent from the REST benefits above, REST is a pragmatic way of building services and this pragmatism currently means there is no metadata. In other words the consumer has to implicitly know what a service requires and what it may return. Hopefully testing the application should drive out whether assumptions about message formats are correct and the pragmatism does not absolve the service provider from taking a responsible attitude to service evolution.
No standard for actions

The next valid actions are a crucial concept in REST and yet there is no standard way of encoding this information and no agreed place of putting this information. There has been some discussion about using ATOMPub as a mechanism but this is far from an agreed standard.
Tooling is rudimentary

On the .NET platform there is little tool support for consuming REST services. With the lack of metadata you are left with having to consume the saw format of the message whether this XML, JSON, an image or something else. There is growing support on the service side with .NET 3.5 WCF extensions and the upcoming ASP.NET routing infrastructure shipping in .NET 3.5 SP1.

Conclusion

REST is a very powerful way to build services. The model lends itself to high scalability as it uses the same model as the web. It is particularly applicable to services that are exposed on to the public internet as generally all a consumer needs to be able to do is manipulate XML and talk HTTP - which every platform supports.

In the first part of this article I have introduced REST and outlined its benefits and issues. In part two I will show you how to build and consume REST based services using WCF, ASP.NET and LINQ to XML.