Evaluating REST Frameworks Part 1: A Maturity Model

REST has been a very important topic of discussion for a while. This series attempts to provide a comparison of some current frameworks that support the development of systems that should be REST-compliant, regardless of the underlying protocol (typically HTTP). To begin, we need a criterion to perform this comparison and that’s what we’ll build in this first article by

  • Explaining what we understand about REST and what is it for.
  • Making a list of what is needed to create a REST compliant application.
  • Determining which features we may expect in a framework that supports REST development.
  • Proposing a maturity model we can use as a tool for evaluation/grading of existing frameworks.

I’m not a maturity model fan, but they can be very handy for evaluation and comparisons since they define a usable criterion and in particular, a grade or level to assign.

A Quick REST Primer

Let’s start with a quick discussion of what REST really means. N.B. The objective of this article is not to provide an in deep explanation of REST. That is better left to Roy T. Fielding’s original dissertation and the O’Reilly book, REST In Practice by Jim Webber, Savas Parastatidis and Ian S Robinson. The Yahoo Rest Discuss group is also the best place to go for any further questions you might have.

REpresentational State Transfer, or REST for short, is an architectural style capable of supporting all the quality attributes required to construct The Web, namely: Anarchical Scalability, Low entry Barrier, Independent Deployment and the like. In general, it is focused on the transfer of large hypermedia content in a networked system. Its creator, Roy T. Fielding, developed it by first analyzing what quality properties were required for the modern web, and then grading several known architectural styles, picking and mixing the ones that better achieved those properties. Although the individual architectural styles can be applied independently, Fielding’s idea was to actually apply them in combination, and that is why he presented them in an incremental, additive way. REST is a combination of all the styles below. Let’s take a look at them in the same fashion as in his dissertation:

  1. Client Server (CS). This is an old architectural style. The server provides a Service and the Client consumes it. The CS idea in REST is to be used for decoupling presentation from processing. The client deals with presentation and the server is the one holding the resources and doing any processing.
  2. CS + Stateless Communication (SC). Since we need scalability, we need to avoid server side sessions. We do that by keeping all information needed for a transaction, in the message. That is, the messages are self-descriptive and no session information is held on the server.
  3. CS+SC+Cache (C$). Since we are making the message bigger, and thus increasing communication cost, we need something to reduce network use and latency. A cache system is a nice addition.
  4. CS+SC+C$+Uniform Interface (UIF). The UIF is the implementation of a known principle, called “The Principle of Generality”, but applied to interfaces. The idea is that all components share the same interface definition, a generic one, which follows four specially crafted constraints:
    1. All resources are uniquely identified.
    2. Manipulation of those resources is done using representations through messages.
    3. Those messages are self-descriptive.
    4. Hypermedia is used as the engine of application state. These constraints will provide better transaction visibility and simplifications of the architecture which will in turn lower the entry barrier and promote independent deployment.
  5. CS+SC+C$+UIF+Layered System (LS). To support larger deployments and simplification, a layered style is proposed. Each component layer should be abstracted from the system’s complexity by only talking to an immediate layer above or below. Those layers can then in turn talk to other layers, etc. That makes it simpler to compose complex transactions while hiding that complexity from the current layer’s view. This adds overhead of course, but that can be reduced with shared caches.
  6. CS+SC+C$+UIF+LS+Code On Demand (CoD). This is an optional style, and presents a way to help the clients. It allows the code that processes some data, to travel with that data from the server to the client, to process the data on the client side. This simplifies the client itself (there is no need for a client to know how to process every data type in the world).

As an architectural style itself, REST must define the elements an architect should use to create a compliant architecture. Here are the components defined by REST:

  1. Data Elements: In REST, the main data element is the resource (which may be anything, implemented however you want and whose implementation is totally hidden, encapsulated). Any resource needs to have a unique identifier that is used to reference it. The resource may have one or more representations that are not the resource itself (representations are the ones transmitted to the client). We can have resource metadata and also representation metadata. And of course, there should be control data as well.
  2. Connectors. Since REST applications are networked ones, we need elements for communicating between components. These are called connectors. Some are intelligent pieces of software or hardware, some others just plain interfaces to components. Examples are the client and server libraries used for communication, the cache (which represents an interface for accessing resources), resolvers and tunnels.
  3. Other Processing Components. In this group we have the actual origin server (the processing node that handles the requests to the server), the user agent (the one that uses the client connector to talk to the server) and intermediary components such as proxies and gateways.

Summarizing REST Application Needs

From what we just described, it is clear that REST applications obey a set of special restrictions. REST is not suitable for all applications. It is specially designed for network applications with a strong need of hypermedia sharing and not much processing. Glenn Block, Senior Project Manager at Microsoft has proposed this list of basic requirements for RESTful Applications (which is directly derived from the constraints above):

  1. Must be a client-server application.
  2. Must be stateless i.e. it cannot rely on traditional server-side mechanisms like server state to track clients.
  3. Must have tolerance for latency. Applications that communicate in real time do not play well with REST.
  4. Clients and servers must exchange data via the uniform interface. They cannot be coupled to implementation details or require out of band knowledge. For example, applications that make direct remote procedure calls such as via SOAP Service proxies are not RESTful as they require a WSDL definition file in which is based on the server’s implementation.
  5. The server must offer up links to the client which it will use to navigate the system
  6. Client and server messages must contain in addition to business data, control data that is used to process the messages.

That list is great. Still, there are a couple more of REST application characteristics we should care about: