Constraints that compose the REST architectural style
Provides the separation of user interface concerns (client) from data storage concerns (server). This improves the portability of the user interface across platforms and improves scalability by simplifying the server components. It allows the components to evolve independently.
Each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is kept entirely on the client. This constraint improves:
- visibility - the server does not have to look beyond a single request in order to determine the full nature of the request
- reliability - it is easier to recover from the partial failures
- scalability - server component can quickly free resources because it does not have to store state between the requests.
The goal of this constraint is to improve the network efficiency. It requires that the data within a response to a request be implicitly or explicitly labeled as cacheable or non-cacheable. If a response is cacheable, then a client cache is given the right to reuse that response data for later, equivalent requests.
Uniform interface between components
This constraint brings the overall system architecture is simplification and the improvement of visibility of interactions. REST is defined by four interface constraints:
- identification of resources - individual resources are identified in requests using URIs as resource identifiers; the resources themselves are conceptually separate from the representations that are returned to the client
- manipulation of resources through representations - when a client holds a representation of a resource, including any metadata attached, it has enough information to modify or delete the resource on the server, provided it has permission to do so
- self-descriptive messages - each message includes enough information to describe how to process the message
- hypermedia as the engine of application state (HATEOAS) - links are contained in the returned body (or headers) to supply the URI for retrieval of the object itself or related objects
Allows an architecture to be composed of hierarchical layers by constraining component behaviour such that each component cannot “see” beyond the immediate layer with which they are interacting.
REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts. This simplifies clients by reducing the number of features required to be pre-implemented. Allowing features to be downloaded after deployment improves system extensibility. However, it also reduces visibility, and thus is only an optional constraint within REST.
- wikipedia: Representational state transfer
- Fielding Dissertation: CHAPTER 5: Representational State Transfer (REST)
- REST API Tutorial