REST - Representational State Transfer

REST is a way to access documents and resources using a simple remote software architecture, represented by an API. Sites using this communication model are said "RESTful".

The definition of name: Representational State Transfer can be understood as describing a transfer mode where each request contains all the information necessary for the communication between the client and the server (usually it is a URL and parameters according to the GET or POST method ). The client sends a request and obtains a representation of the resource in its current state.
For example, if the client wants to receive a page, it sends the URL to the server. The server sees the page as a resource whose it must send the current state (a document specified by the URL may change, especially it it is a web page) and it provides a copy to the client, a representation of the current state.
Obviously this choice of words is the result of some cerebration by the author of the model (Roy Fielding) to arrive at the REST name, which is the idea that he wanted to give: a simple and safe system.

The Web (World Wide Web) is an application of the REST architecture, that until the arrival of WebSocket and WebRTC. However the REST architecture does not necessarily use HTTP or the Web.

REST architecture

The alternatives are SOAP, RPC, with XML or JSON for the file format.
And also WebSockets. It allows  notifications by the server, which is beyond the scope of the REST architecture. It is better suited for rapid  and constant exchanges, and REST more efficient on bandwidth, is more suitable for simple queries.

How it works

This architecture is defined as follows:
- States and functions of a remote application are considered as resources.
- Each resource is only accessible using a standard address. These are hyper links. Under HTTP these are URIs.
- Resources have a standard interface in which the transactions and data types are precisely defined. XML or JSON for example, or HTML.
- Date exchange is carried out according to a protocol that has the following properties:

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

HTTP commands

HTTP commands allow access to resources of a server.
GET to request data, for example loading a page, adds key/value pairs in the URL of the page or script.
POST to send data to the server, for example data of a form, embedded in the HTTP message (and not the URL), where a script will process them.
Other commands still exist but are rarely used: PUT (replace) and DELETE (erase).
The use of cookies, retaining data on the service, cancels the stateless property and just make the service less efficient.

Benefits of REST

- Easier to implement than the legacy alternatives (we do not speak of WebSockets).
- Only a browser is needed to access a service.
- Caching of resources, thus speeding up operations.
- Less memory use than others.
- Possibility to distribute queries across multiple servers. Thanks to the absence of states.
- Using standard formats as HTML or XML ensures compatibility over time.
- Requests may be exchanged between various media applications as they are represented by URIs.

Disadvantages

- The data necessary to use the web service must be kept locally.
- Less secure than architectures based on a protocol as SOAP.

Reference: Architectural Styles and the Design of Network-based Software Architectures.