REST stands for REpresentational State Transfer and marks a software architecture pattern (in contrast to SOAP which is a protocol).
Using REST, we are talking about performing operations on resources via the HTTP protocol. First of all, this includes the so called CRUD operations (Create, Read, Update, Delete). Moreover, REST can be used to query resources in an easy and natural way.
One of the most important constraints of REST is statelessness on the server side. This means, the server does not hold a session or a similar kind of request-dependent server state. This implies great possibilities for an easy, automatic and transparent way of caching server responses.
REST uses the HTTP protocol to identify, query and manipulate resources in a computer network. To fulfill its task, REST uses the information provided by the HTTP protocol. Namely these are:
An URL is responsible for allocating a resource and can contain parameters in its query part. The HTTP method is used for choosing the right action to be performed on the resource. Request headers provide meta data for accessing a resource. The request body provides the resource input in case of POST and PUT requests.
Each HTTP method is assigned to perform a certain action on a resource, depending on the effects which the task has on a resource. Let's have a look on the most important HTTP methods and their tasks:
A safe method has no effect on the resource itself. It will not change the resource, nor does it have any other kind of side effects. Using the HTTP method 'GET' must not change the resource. A method which is not safe, may effect the resource. As you can see, POST, PUT and DELETE are not safe because their tasks imply to almost always manipulate a resource.
Using a safe method means that the result cache may not be invalidated in any case.
An idempotent method can be called multiple times in a row and will always lead to the same result if the requests are identical. Of course, the task of the DELETE method will always result into a state where the resource will not be present on the server any more. Using PUT, the resource will most likely change its state, but performing two identical updates will not change a resource's state.
The difference between creating a resource via POST or PUT can best be explained by imaging the creation of a new data set in a data base. When the data base (manager) automatically generates an artificial identifier for the resource, then the same request performed twice will result into two different states. In cases like that, POST has to be used instead of PUT.
Using two identical idempotent method requests in a row, the second request is not forced to be executed and instead the cached result of the first one can be returned. Using POST always forces a cache invalidation. Beside the already discussed HTTP methods, REST also makes use of some less used HTTP methods.
OPTIONS works pretty straight forward and its result can and should be auto generated by the server. This way, it can be implemented as a dynamic documentation of resources.
HEAD returns the headers which would have been returned in the case of calling GET on the same resource. The most common use cases for HEAD is for either cache-control or the estimation of size, media type and encoding of a resource.
HTTP headers are used as additional meta data of a request. Let's take a look on some important headers and their meaning for REST:
Other headers may play an important role for caching or authentication. In general, you can expect them to fulfill the same tasks in REST as defined by the HTTP protocol.
URL parameters are used as input parameters of resource implementations. You can assume them to act like a method parameter in a programming language. URL parameters are used with the HTTP methods GET and DELETE and are limited in their length. Using REST the right way, this limitation should be without consequences because these methods are meant to be called in a query style rather than accepting large amounts of data.
The request body is only to be used with the HTTP methods POST and PUT. In combination with the Content-Type being set to application/x-www-form-urlencoded, it exactly acts the same way as URL parameters do, given the body content to be URL-encoded. This kind of parameters are often called form parameters and do not underlie a limitation of length.
Both mentioned approaches of transporting data lack of the ability of carrying information about the content-type of the individual parameters. They force the server to guess an input's content type depending on what kind of input is expected by the resource implementation in combination with the input data. This is no problem for querying HTTP methods like GET, which usually only contain easily identifiable primitive-like values.
For complex data like XML, JSON, image or binary data the situation is different. First of all, for these kind of data using application/x-www-form-urlencoded is a very bad idea in regard to load. Second, it is not possible to handle this data in a natural way and makes deserialization quite inefficient. So, being able to identify the content's media type properly, will lead to an efficient, stable and secure deserialization. That is why, whenever possible, the Content-Type of the request body should be set to the media type of the transported content.
Although REST is often regarded as a good attempt for an exchange between servers, this is just one part of the story. Imagine, you develop a web application and want to provide an API (like Twitter or Amazon) using REST. Further, let us assume that your web application will make heavy use of AJAX. Very soon, you will find that many resource implementations for your API and your AJAX communication are redundant or so similar that they could easily be merged. And you will remind: REST can be used by any kind of client that fully implements HTTP.
All commonly used browsers support the four important HTTP methods for the XMLHttpRequest. However, it is important to mention that sometimes you might only be able to use GET and POST (e.g. in an HTML form). For these cases, it is possible to channel other HTTP methods through GET and POST as follows:
As long as GET and POST are available HTTP methods, you are still able to use REST with very view restrictions, because the special caching behaviour of PUT and DELETE are not a big deal in practice. For caching performance, making a difference between a safe and an unsafe methods is very much more important then making a difference between an idempotent and a not-idempotent method.