What is REST?
REST (REpresentational State Transfer) - is an architectural style for providing standards between computer systems on the web, making it easier for systems to communicate with each other. While REST can be used over nearly any protocol, it usually takes advantage of HTTP when used for Web APIs. REST-compliant systems, often called RESTful systems, are characterized by set of constraints:
Uniform Interface
The key to the separating client from server is having a uniform interface that allows independent evolution of the application. This interface should provide an unchanging, standardized means of communicating between the client and the server, such as using HTTP with URI resources, CRUD operations and JSON format.
Four guiding principles of the uniform interface are:
Resource-Based
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.
HATEOAS (Hypermedia as the Engine of Application State)
Clients deliver state via body contents, query-string parameters, request headers and the requested URI. Services deliver state to clients via body content, response codes, and response headers. This is technically referred-to as hypermedia.
Aside from the description above, HATEOS also means that, where necessary, links are contained in the returned body (or headers) to supply the URI for retrieval of the object itself or related objects.
Stateless
REST APIs are stateless, it mean that calls can be made independently and each call contains all of the data necessary to complete itself successfully. A REST API should not rely on data being stored on the server or sessions to determine what to do with a request, but on the data that are provided. Each request has the necessary data in itself, such as the API key, access token, user ID, etc. This also helps increase the API’s reliability by having all of the data necessary to make the call.
Cacheable
Because a stateless API can increase request overhead by handling large loads of calls, a REST API should be designed to encourage the storage of cacheable data.
This means that when data is cacheable, the response should indicate that the data can be stored up to a certain time or in cases where data needs to be real-time, that the response should not be cached by the client. This kind of cache is managed via HTTP headers like Cache-Control or Expires. There are also another approaches for cacheing data and increase performance like for example reverse proxy (varnish) or application managed cache (redis).
Client-Server
The client-server constraint works on the concept that the client and the server should be separate from each other and allowed to evolve individually and independently. This creates a separation of concerns, letting each application grow and scale independently of the other.
Layered System
As the name implies, a layered system is a system comprised of layers, with each layer having a specific functionality and responsibility. In REST API design different layers of the architecture working together to build a hierarchy that helps create a more scalable and modular application.
Code on Demand (optional)
Perhaps the least known of the six constraints, and the only optional constraint, Code on Demand allows for code or applets to be transmitted via the API for use within the application. In essence, it creates a smart application that is no longer solely dependent on its own code structure. However, perhaps because it’s ahead of its time, Code on Demand has struggled for adoption as Web APIs are consumed across multiple languages and the transmission of code raises security questions and concerns.