- REST Architectural Constraints
Six guiding constraints define a RESTful system. These constraints restrict the way the server can process and respond to client requests so that, by operating within these contraints, the system gains desirable non-functional properties (architectural properties).
Principle behind this is the separation of concerns. Separating the user interface concerns from the data storage concerns, improves portability of the user interfaces across multiple plataforms. It also improves scalability by simplifying server components, also, allowing components to evolve independently.
Client-server communication is constrained by no client context being stored on the server between requests. Each request from any client contains all the information necessary to service the request, and the session state is held in the client.
Session state can be transferred by the server to another service such as a database to persist state for a period and allow authentication.
Responses must, implictly or explicitly, define themselves as either cacheable or non-cacheable to prevent clients from providing stale or inappropriate data in response to further requests.
Well-managed caching partially or completely eliminates some client-server interations, further improving scalability and performance.
A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way.
If a proxy or load balancer is placed between the client and server, it won't affect their communications and there won't be a need to update the client or server code.
Intermediary servers can improve systems scalability by enabling load balancing and by providing shared caches. Also, security can be added as a layer on top of the web services, and then clearly separate business logic from security logic.
Finally, it also means that a server can call multiple other servers to generate a response to the client.
Servers can temporarily extend or customize the functionality of a client by transferring executable code, for example, compiled components such as Java applets, or client-side scripts such as JavaScript.
The uniform interface constraint is fundamental to the design of any RESTful system. It simplifies and decouples the architecture, which enables parts to evolve independently.
There are four constraints for this uniform interface:
Individual resources are identified in requests. Resources themsleves are conceptually separate from the representations that are returned to the client. For example, server could send data from its databas as HTML, XML, or as JSON, none of which are the server's internal representation.
When a client holds a representation of a resource, including any metadata attached, it has enough information to modify or delete the resource's state.
Each message includes enough information to describe how to process the message. For example, which parser to invoke can be specified by a media type.
Having accessed an initial URI for the REST application, a REST client should then be able to use server-provided links dynamically to discover all the available resources it needs.
As access proceeds, server responds with text that includes hyperlinks to other resources that are currently available. There is no need for the client to be hard-coded with information gathered about the structure or dynamics of the application.