The REST architectural
style describes the following six constraints applied to the architecture,
while leaving the implementation of the individual components free to design:
Uniform interface: The uniform interface between clients and servers, discussed below,
simplifies and decouples the architecture, which enables each part to evolve
independently. The four guiding principles of this interface are detailed
below. The only optional constraint
of REST architecture is code on demand. If a service violates any other
constraint, it cannot strictly be referred to as RESTful. Complying with these constraints, and thus conforming to the REST
architectural style, will enable any kind of distributed hypermedia system to
have desirable emergent properties, such as performance, scalability,
simplicity, modifiability, visibility, portability and reliability.
Client–server: Clients
are separated from servers by a uniform interface. This separation of concerns
means that, for example, clients are not concerned with data storage, which
remains internal to each server, so that the portability of client code is
improved. Servers are not concerned with the user interface or user state, so
that servers can be simpler and more scalable. Servers and clients may also be
replaced and developed independently, as long as the interface is not altered.
Stateless: The
client–server communication is further constrained by no client context being
stored on the server between requests. Each request from any client contains
all of the information necessary to service the request, and any session state
is held in the client. The server can be stateful; this constraint merely
requires that server-side state be addressable by URL as a resource. This not
only makes servers more visible for monitoring, but also makes them more
reliable in the face of partial network failures as well as further enhancing
their scalability.
Cacheable: As
on the World Wide Web, clients are able to cache responses. Responses must
therefore, implicitly or explicitly, define themselves as cacheable, or not, to
prevent clients reusing stale or inappropriate data in response to further
requests. Well-managed caching partially or completely eliminates some
client–server interactions, further improving scalability and performance.
Layered system: A
client cannot ordinarily tell whether it is connected directly to the end
server, or to an intermediary along the way. Intermediary servers may improve
system scalability by enabling load balancing and by providing shared caches.
They may also enforce security policies.
Code on demand (optional): Servers are able to temporarily extend or customize
the functionality of a client by transferring logic to it that it can execute.
Examples of this may include compiled components such as Java applets and
client-side scripts such as JavaScript.