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 his 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 acme corp. Order system. SOAP sends a message, using HTTP POST, to the order system endpoint (say, http://www.acme.com/orderservice) with an action header of GetProducts. With REST we issue an HTTP GET to the URI http://www.acme.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://acme.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://acme.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.
Comments