RESTFUL WEB SERVICES - Java EE Design Patterns - page 168

Stateless
The server should not maintain client state. In other words, each message/request is self‐descriptive;
it has enough information or context for the server to process that message. This implies that if
there is state, it is maintained on the client side. The advantage of this constraint is that it increases
scalability, reliability, and visibility. The disadvantage is that it decreases performance because
messages need to be larger to maintain stateless communication.
Cacheable
The server responses must be cacheable. The RESTful interface should provide a mechanism for
marking messages as cacheable or noncacheable. This can be implicit, explicit, or negotiated and
allows the client to reissue a message if necessary.
Layered System
The client cannot assume direct access to the server. The response may be a cached response, or it
may retrieve the resource directly from the server. This improves scalability because there might be
software or hardware between the client and the server.
Code on Demand
This constraint dei nes a REST architecture as consisting of hierarchical layers that are limited
to communicating with their immediate neighbors. This separation of concerns simplii es the
architecture and isolates disparate and legacy components. The principle benei t you receive is an
increase in scalability because new components can be easily introduced and obsolete ones retired or
replaced. The drawback of this constraint is a reduction in the system's performance resulting from
the increased indirection related to the multiple layer structure.
This constraint allows a client to download and execute code from the server, which enables the
server to temporarily extend the client by transferring logic. This may be in the form of a JavaScript
snippet. The code on demand constraint is the only optional one.
Violating any of these constraints (except code on demand) means that the service is not strictly
RESTful. A constraint violation does not mean the service is not a viable and useful implementation,
however.
RICHARDSON MATURITY MODEL OF REST API
You have already read about how a truly RESTful API achieves level 3 of the Richardson Maturity
Model. Now you'll look a little deeper and examine each level on the model.
The model, developed by Leonard Richardson, attempts to classify an API according to its
adherence to the constraints imposed by REST. The more compliant your implementation, the
better it fares. There are four levels. The bottom is level 0, which designates the less compliant
implementation, and the top is level 3, which is the most compliant and therefore the most
RESTful. 4