REST - REpresentational State Transfer

REST is a way to access remote documents and resources through a simple software architecture represented by the API. They say "RESTful" sites use this communication model.

Name definition: Representative State Transfer can be understood as a description of the transfer mode, in which each request contains all the information necessary for communication between the client and the server (usually URLs and parameters in GET or POST mode). The client sends a request and receives a view of the resource in its current state.
For example, if a client wants to receive a page, it sends its URL to the server. The server considers it a resource that takes in the current state (a document designated by a URL can evolve, especially if it is a web page) and sends a copy to the client, a representation of the current state.
Obviously, this choice of terms became the subject of a certain unification on the part of the model author (Roy Fielding) to get the name REST, which means "to be calm" in English and is the idea he wanted to give: a simple and safe system.

Web (World Wide Web) is a REST architecture application, this is up to the advent of WebSocket and WebRTC. However, the REST architecture does not necessarily use HTTP or Web.

Alternatives are SOAP, RPC, with XML or JSON for file format.
As well as WebSockets. It allows you to receive notifications from the server, which is not part of the REST architecture. It is better suited for fast and constant exchange, and REST is more economical in bandwidth, suitable for more point requests.

How REST works

Its architecture is defined as follows:
- The states and functions of the remote application are considered resources.
- Access to each resource is carried out only in the standard address format. These are hypertext links (or hypermedia). There will be a URI under HTTP.
- Resources have a standard interface in which operations and data types are precisely defined. For example, XML or JSON, or HTML .
- Data is exchanged over a protocol that has the following properties:

• Client-server.
• No states (represented by variables).
• Enables caching.
• Multi-level software.

- Independence of the interface from added services such as proxies, firewalls and others.

HTTP Commands

HTTP commands are used to access server resources.
GET to request data, such as page loading, by sending key/value pairs to the URL.
POST to send data to the server, such as form data, in an HTTP message (not a URL), where the script processes it.
Other commands still exist, but are rarely used: PUT (substitution) and DELETE (deletion).
The use of session cookies, while storing data related to the service, invalidates the "stateless" property and may make the service less efficient.

REST Benefits

• It is easier to implement than classic alternatives (we are not talking about WebSockets).
A
• browser is enough to access the service.
• Resource caching, so faster operations.
• Less memory consumption.
• Ability to distribute requests across multiple servers. This is due to the absence of states.
• Using standard formats such as HTML or XML provides temporal compatibility.
• You can exchange requests between different applications or media because they are URIs.

Inconveniences

• The data required to use the web service must be stored locally.
• Less secure than protocol-based architectures such as SOAP.

References and resources: Roy-Fielding dissertation. Translation of the document that inspired the REST architecture. Original in English.