186 | Chapter 7: REST, Resources, and Web Services
Stateless
The server may not hold persistent state about its sessions with the client. Each
request from client to server is independent and self-contained. This increases
verbosity, but aids reliability and scalability. When there is little or no stored
context on a server, the system is more resilient to periodic failure, and there are
fewer requirements for inter-server coordination when the system is scaled up.
Cache
This step requires the server to indicate whether or not the client may cache a
response, and to define parameters for such caching. Providing explicit cache
control information allows the client to cache more aggressively, reducing net-
work traffic and increasing performance.
Uniform Interface
A uniform interface is the primary item that distinguishes REST from RPC and
other network styles. Forcing the client and server to communicate using a well-
known uniform interface pushes the application-specific complexity out of the
network layer into the application layer, where it belongs. It allows standardized
software components to be reused for vastly different applications, as they speak
the same language.
Layered System
Architectures are permitted to be broken down into independent layers (in
the sense of the OSI or TCP/IP layered models). Each layer mediates only
between the layers immediately adjacent to itself. In this way, layers can
evolve or be replaced independently with minimal impact to the remainder of
the architecture.
Code-on-Demand
Client software is extensible by retrieving and executing code from a server. This
allows clients to expand their capabilities in an ad-hoc manner after an architec-
ture is deployed.
REST is often referred to as anarchitectural style, instead of an architecture. Rather
than defining a specific “best” architecture, REST defines principles by which archi-
tectures are created and evaluated—it puts constraints on network architecture.
We often use a linguistic analogy to explain REST; in many ways, the REST princi-
ples are modeled on human communication. Resource names are “nouns,” as they
refer to things. It is important to remember the distinction between resources and
their names. Just as the word “apple” is not itself an apple, the namehttp://
example.com/person/123is just a name, not the resource itself. A corollary is that a
resource may have many names (though good REST style indicates that this should
be kept to a minimum, where possible).
In the same way, HTT Pmethods are referred to as “verbs” because they specify an
action on a resource or its representation.