Representational state transfer

Representational state transfer (REST) is a software architectural style for distributed hypermedia systems. It provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems.
The terms "representational state transfer" are intended to evoke an image of how a well-designed Web application behaves: it is a network of resources (a virtual state-machine) where the user progresses by selecting hyperlinks embedded in a resource's representation (application state transition), resulting in the next resource's representation (the next application state) being transferred to the user.
History.
Roy Fielding defined the REST architectural style in his 2000 doctoral dissertation "Architectural Styles and the Design of Network-Based Software Architectures" at UC Irvine. It is a formalization of the "HTTP object model" that he developed in 1994 and 1995, as he was authoring the HTTP/1.0 specification and designing HTTP 1.1.
In a retrospective look at the development of REST, Fielding said:
Architectural constraints.
The following set of architectural constraints define the REST architectural style.
Client–server.
The "client–server" constraint requires that the user interface concerns be separated from the data storage concerns.
The advantage of this constraint is that it improves the portability of the user interfaces across multiple platforms. It also improves scalability by simplifying the server components. Perhaps most significant to the Web is that the separation allows the components to evolve independently, thus supporting the Internet-scale requirement of multiple organizational domains.
Stateless.
The "stateless" constraint requires that no application state be kept on the server, so that each request contains all of the information necessary to understand the request and cannot take advantage of any stored context on the server.
The advantage of this constraint is that it improves visibility, reliability and scalability. Visibility is improved because a monitoring system does not have to look beyond a single request datum in order to determine the full nature of the request. Reliability is improved because it eases the task of recovering from partial failures. Scalability is improved because not having to store state between requests allows the server component to quickly free resources, and further simplifies implementation because the server doesn't have to manage resource usage across requests.
The disadvantage of this constraint is that it may decrease network performance by increasing the repetitive data (per-interaction overhead) sent in a series of requests, since that data cannot be left on the server in a shared context. In addition, it reduces the server's control over consistent application behavior, since the application becomes dependent on the correct implementation of semantics across multiple client versions.
Cache.
The "cache" constraint requires that responses be implicitly or explicitly labeled as cacheable or non-cacheable to let the client or server save cacheable responses so that they can be reused for later equivalent requests, by the client to avoid repeating the network interaction, or by the server to avoid repeating the response generation.
The advantage of this constraint is that it can partially or completely eliminate some interactions, improving efficiency, scalability, and user-perceived performance by reducing the average latency of a series of interactions.
The disadvantage of this constraint is that a cache can decrease reliability if stale data within the cache differs significantly from the data that would have been obtained had the request been sent directly to the server.
Uniform interface.
The "uniform interface" constraint requires a uniform interface between components, which is the core feature of the REST architectural style. It is accomplished by the following four constraints:
The advantage of this constraint is that the overall system architecture is simplified and the visibility of interactions is improved. Implementations are decoupled from the services they provide, which encourages independent evolvability.
The disadvantage of this constraint is that it degrades efficiency, since information is transferred in a standardized form rather than one which is specific to an application's needs. The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction.
Layered system.
The "layered system" constraint requires that components cannot see beyond the immediate layer with which they are interacting.
The advantage of this constraint is that is reduces the overall system complexity and promotes substrate independence. Layers can be used to encapsulate legacy services and to protect new services from legacy clients, simplifying components by moving infrequently used functionality to a shared intermediary. Intermediaries can also be used to improve system scalability by enabling load balancing of services across multiple networks and processors. Such layers also allow security policies to be enforced on data crossing the organizational boundary, as is required by firewalls.
The disadvantage of this constraint is that they add overhead and latency to the processing of data, reducing user-perceived performance. This can be offset by the benefits of shared caching at intermediaries.
Code-on-demand (optional).
The "code-on-demand" constraint allows servers to extend client functionality by transferring executable code in the form of applets and scripts.
The advantage of this constraint is that it simplifies clients by reducing the number of features required to be pre-implemented. Allowing features to be downloaded after deployment improves system extensibility.
The disadvantage of this constraint is that it reduces visibility, and thus is only an optional constraint within REST.
Architectural properties.
By operating within the REST architectural constraints, an architecture gains the following non-functional properties:
Common misconceptions.
Fielding stated the rules related to the HATEOAS constraint that are most often violated within so-called REST APIs:
Relationship to the Web.
Web implementations are not equivalent to Web architecture and Web architecture is not equivalent to the REST architectural style:
Leonard Richardson has developed a maturity model based on the adoption of the three core standards of the Web (URI, HTTP and HTML) to help classify the RESTfulness of a Web application, as these technologies are the real-world implementation of the RESTful constraints. A Web application achieves level 1 when it adopts URI to reduce complexity by spreading it across multiple resources, level 2 when it also adopts HTTP to optimize component interactions by using the specialized methods GET, PUT and DELETE for CRUD operations instead of the generic method POST exclusively, and level 3 when it also adopts HTML to drive application state transitions by presenting hyperlinks between resources dynamically.