Understanding REST

There are a lot of people talking about REST (1) yet very few actually have taken the time to read Roy Fielding's thesis about it. This blog post will attempt to explain REST in a simplified manner to convey the basics. Please do not consider this authoritative however. REST means different things to different people at this time and this blog post is based on REST as per Fielding's work.

First and foremost, REST does not equate to HTTP and XML. REST is an architectural style. Encapsulated within the REST style are several key principles governing network architecture. While the HTTP/XML confusion reigns in most articles, it is in fact possible to write an HTTP and XML interface to a resource that does not comply with the principles of REST.

REST can be simplified down to the following:

1. REST begins with the notion of a null architectural style (imagine that there is only a "thing" with no discernible detail). From this emptiness, the first constraints of REST emerge. A client-server architecture is the first emergent principle; a separation of all into two concern groups. This allows each group to evolve separately and scale across multiple domains (similar to SOA).

2. REST then adds the principle of stateless binary relationships. In section 5.1.3 of his dissertation, Fielding writes "each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server". These types of requests are also termed "idempotent". Inference? Any site using cookies or stored contexts is not compliant with REST.

3. REST does make the possibility of caching available to improve efficiency. While not violating the principles of stateless invocations, client side caches can be used to allow reuse of information.

4. Uniform interfaces and uniquely identified resources are pivotal to being RESTful. Having a uniform interface between components (such as the use of certain methods like GET, POST, PUT and DELETE in protocols like HTTP), enables implementations to be decoupled from the service interfaces. This principle is also embodied in Service Oriented Architecture, which perplexes me why so many people compare SOA to REST.

Fielding writes more about the subject in section 5.1.5 "In order to obtain a uniform interface, multiple architectural constraints are needed to guide the behavior of components. REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state."

5. A resource is explicitly defined as "the intended conceptual target of a hypertext reference" and later in section 5.2.1.1 as "any information that can be named...". The first of these definitions seems to concretely link HTTP to REST yet there are arguments that hypertext is used here in a generic manner. In fact, later in section 5.2, it quite explicitly states "REST ignores the details of component implementation and protocol syntax in order to focus on the roles of components". Nevertheless, the way to interact with resources is via representations of the resources, as per 5.1.5. Note that Resource is defined in W3C terms as "any thing that can have an identifier".

6. Resources are identified with a URL or URN. Note that in this case, the URL should be constrained to be free of non-uniform interfaces (such as http://www.domain.com/someOperation?operation=manipulationByURL&moreOperations=notAllowed). This style of manipulation of data elements through invocation of non-standard operations is the anti-pattern or REST. REST therefore can be contrasted to Remote Procedure Calls (RPC) which generally encapsulate the notion of invoking a procedure on a remote server.

REST is an abstraction of all these architectural elements plus a few more within a distributed hypermedia system such as the Internet. Now here is the one sentence summary:

REST-based architectures communicate primarily through the exchange of representations of the state of resources through uniformly defined interfaces.

Try saying that 5 times fast.

So is it possible to define RESTful services for SOA? Absolutely. Do you have to use XML in REST? No.

There is a lot more about REST that you should look at in detail but I think this captures the gist.

Don't believe me though - read about it here yourself. http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

References:

(1) Fielding, Roy Thomas. Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine, 2000