Breaking Down the REST Dissertation, Part 5: REST Constraints

Previously, we talked about the role of properties when evaluating architectures for network-based applications. We also talked about the paper's working definition of architectural elements such as components along with the requirements of the web. Now we will use that knowledge to understand the paper's definition of REST architecture as a set of constraints.

According to the REST dissertation, a constraint is a rule that induces one or more software architecture properties. A group of constraints is called a style. The REST style is a group of six major constraints that induce the various properties needed for the Web. In order for an
architecture to be deemed a REST architecture, it must satisfy all of these constraints.

The first major constraint is the client-server constraint. The client-server constraint is based on a principle in software known as the separation of concerns. It simply requires the existence of a client component that sends requests and a server component that receives requests. After receiving a request, the server may also issue a response to the client. An example of the client-server constraint is the separation of the user interface of a banking application into a client from the request-handling logic which would reside on the bank's servers. The properties induced by the client-server constraint are portability, evolvability, and scalability.

The layered system constraint defines a REST architecture as hierarchical layers of components, limited to communication with their immediate neighbors. Similar to the client-server constraint, this constraint improves simplicity by separating concerns. It also improves extensibility by using layers as a mechanism to isolate
legacy components. Scalability is increased by providing the capacity for intermediary
components that act as caches or load balancers. The trade off with this constraint is
reduced performance from the increased levels of indirection associated with multiple layers.

The stateless communication constraint requires every request to contain all of the information needed to interpret that request. This increases visibility, reliability, scalability, but also decreases performance because of the larger messages required for stateless communication.

The caching constraint states that a REST architecture must have some mechanism for labeling messages as cacheable or non-cacheable. This gives a client or intermediary
component permission to cache and reissue a message which increases efficiency, scalability and performance.

The code on demand constraint is an optional constraint. Code on demand allows a client to download and execute code from a server. This allows the client functionality to be extended after initial deployment of the application. This has an effect on simplicity as well, because it promotes the reduced coupling of features. Scalability is also increased by virtue of the server off-loading work onto the clients. The trade off is the reduced visibility generated by the code itself, which is hard for an intermediary to interpret. With this constraint being optional, the preferences of different organizations are served by allowing them the flexibility to deploy only when the trade-offs of deployment are worth it.

At a high level the uniform interface constraint basically means the interface for a component needs to be generic as possible. This increases evolvability, simplicity, and visibility but has the side effect of reducing efficiency given the nature of generic data. More specifically, the uniform interface constraint is defined by four interface sub-constraints, each of which warrant their own discussion.

Resources and Representations

In order to understand the interface sub-constraints, it is necessary to understand the idea of a resource. The dissertation says a resource is any information that can be named. It also says a resource is a conceptual mapping to a set of entities. In both cases a resource is always a concept, never a concrete thing. An example of a resource
is the current weather in Austin, TX.

A representation is a sequence of bytes and the description of those bytes. Less formally, a representation is one form of a resource. An example of a representation is an html page with an embedded doppler radar PNG image of the current weather in Austin, TX.

Uniform Interface sub-constraints

Resource identification is one of the four interface constraints which basically requires the same authority whom maintains the reference to a resource to also be responsible for preserving meaning of that resource. The idea here is the creator of a resource will be the best agent for naming that resource. This promotes links to resources that don't change over time even if the representations for those resources change.

The second interface constraint states that resources must be manipulated via representations. A client has no access to a resource directly, it can only send and receive representations from the server.

The self descriptive message is the third interface constraint. It states all messages must include metadata which describe the meaning of the message. This means the methods used to invoke the message must be standard and agreeable between the client, the server, and the intermediaries in between. This constraint is also related to the stateless
constraint in that no state on the server is permitted when interpreting a message.

Hypermedia as the engine of application state, otherwise known as the hypermedia constraint, is the last and probably most often overlooked constraint in the REST dissertation. Simply put, the steps in a REST architecture must be invoked through hypermedia. More specifically, in order for an application's process to move a step, it must invoke that next step from a reference inside the current representation. The next step should not be determined from somewhere outside of the currently received representation. For example, if the current representation is an html document, the next legal steps would be links in that html document.

The next article will talk more in depth about how these constraints relate to each other and how they are implemented in the HTTP protocol.

This article was originally published on wwatson.net