REST - Representational State Transfer

REST is a way to access documents and resources using a simple remote software architecture, represented by an API. The Web (World Wide Web) is an application of the REST architecture.

The REST architecture does not necessarily use HTTP or the Web.

REST architecture

The alternatives are SOAP, and RPC with XML or JSON for the file format.
WebSockets too. 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 for more specific requests.

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.

Under HTTP

HTTP commands allow access to resources of a server: GET and POST.
The first is to read, for example load a page, the second is to write, for example, send data from a form to the server, 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 efficent.

Benefits of REST

- Easier to implement than the legacy alternatives (we do not speak of WebSockets).
- Just a browser to access a service.
- Caching of resources, thus speeding up operations.
- Less memory concommation 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.
- We can exchange requests 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.