Representational State Transfer (REST) is a design philosophy that defines six architectural constraints. These constraints govern the large-scale behavior of the participants within a networked software system. The REST design constraints are fully implemented by the HTTP protocol. The World Wide Web is an example of a fully RESTful software system.
It is important to note that just because an application protocol makes use of HTTP, that does not guarantee it to be RESTful. A prominent example is the Simple Object Access Protocol (SOAP), which uses the HTTP protocol to send SOAP messages. The SOAP protocol is however not RESTful.
Design Constraints of a RESTful Architecture
The design constraints of a RESTful architecture are as follows:
- Client Server Architecture
- Cacheability
- Statelessness
- Layered System
- Uniform Interface
- Code on Demand
- Client-Server Architecture
- The participants of a RESTful architecture must implement the client-server model, which allows for the client and server software components to be developed independently. It assumes that the client will take no part in long-term data storage and that the server will take no part in the presentation of the data it supplies. This principle is known as the Separation of Concerns.
- Cacheability
- In order to improve performance and scalability, every server response must carry with it an indicator to denote whether or not it can be cached for future use. This is to prevent the client from working with outdated data.
- Statelessness
- The communication between participants must be stateless. A stateless interface requires the client to supply all the necessary information for the server to process the request. Session information must be held on the client side. The server can hold client state information, however, the state information must be known to, and addressable by the client.
- Layered System
The communication between participants must be layered. When the client communicates with a server, it should not be able to distinguish whether it has communicated with the actual end-point server that will supply the requested information, or some intermediate server used for system scalability or security.
- Uniform Interface
A uniform interface between the clients and servers decouples the architecture. A uniform interface has the following characteristics:
- The server must provide the client with a representation (for example a URL) of its resources.
- A means must be provided for the client to manipulate those resources (for example provide operations such as Create, Read, Update, Delete, and so on).
- All responses sent to the client must be self-describing.
- The manipulation of server-side resources can only be performed by hypermedia (that is links) supplied by the server.
- Code-On-Demand
- The server is able to deliver code-on-demand to the client. At the request of the client, the server should be able to supply additional executable code to extend the client’s capabilities. This is addressed in OData by the use of function imports.