REST - REpresentational State Transfer

REST est un moyen d'accéder aux documents et aux ressources distants selon une architecture logicielle simple, représentée par une API. On dit "RESTful" les sites utilisant ce modèle de communication.

La définition du nom: Representational State Transfer peut se comprendre comme la description d'un mode de transfert où chaque requête reprend toutes les informations nécessaires à la communication entre le client et le serveur (en général il s'agit d'une URL et de paramètres selon le mode GET ou POST). Le client envoie une requête et obtient une représentation de la ressource dans son état actuel.
Par exemple si le client veut recevoir une page, il envoie l'URL de celle-ci au serveur. Le serveur la considère comme une ressource qu'il prend dans son état actuel (le document désigné par l'URL peut évoluer, spécialement si c'est une page web) et envoie une copie au client, une représentation de l'état courant.
Evidemment ce choix de termes a fait l'objet d'une certaine cogitation par l'auteur du modèle (Roy Fielding), afin d'aboutir au nom REST, qui signifie "être au calme" en anglais et qui est l'idée qu'il a voulu donner: un système simple et sûr.

Le Web (World Wide Web) est une application de l'architecture REST, cela jusqu'à l'arrivée de WebSocket et WebRTC. Pour autant, l'architecture REST n'utilise pas nécessairement HTTP ou le Web.

Les alternatives sont SOAP, RPC, avec XML ou JSON pour le format de fichier.
Ainsi que WebSockets. Il permet les notifications par le serveur, ce qui n'entre pas dans le cadre de l'architecture REST. Il convient mieux pour les échanges rapides et constants, et REST plus économe en bande passante, convient pour des requêtes plus ponctuelles.

Comment fonctionne REST

Son architecture se définit ainsi:
- Les états et fonctions d'une application distante sont considérées comme des ressources.
- Chaque ressource est accessible uniquement selon un format d'adresse standard. Ce sont des liens hypertextes (ou hypermedia). Sous HTTP se sera une URI.
- Les ressources ont une interface standard dans laquelle les opérations et types de données sont précisément définis. XML ou JSON par exemple, ou HTML.
- L'échange de données se fait selon un protocole qui a les propriétés suivantes:

Client-serveur.
Sans états (représentés par des variables).
Permet la mise en cache.
En couches logicielles multiples.

- Indépendance de l'interface aux services ajoutés tels que proxies, firewalls et autres.

Commandes HTTP

Des commandes HTTP permettent d'accéder aux ressources d'un serveur.
GET pour requérir des données, par exemple charger une page, en envoyant des paires clé/valeur dans l'URL.
POST pour envoyer des données au serveur, par exemple les données d'un formulaire, dans le message HTTP (et non l'URL) où un script les traite.
D'autres commandes existent encore mais sont peu utilisées: PUT (remplacer) et DELETE (effacer).
L'utilisation de cookies de session, en conservant des données relative au service, annule la propriété "sans état" et peut rendre le service moins efficace.

Avantages de REST

Plus facile à mettre en oeuvre que les alternatives classiques (on ne parle pas de WebSockets).
Il suffit d'un navigateur pour accéder à un service.
Mise en cache des ressources, donc accélération des opérations.
Moins de consommation mémoire.
Possibilité de répartir les requêtes sur plusieurs serveurs. Cela grâce à l'absence d'états.
L'utilisation de formats standards comme HTML ou XML assure la compatibilité dans le temps.
On peut échanger des requêtes entre diverses applications ou média car elle sont représentées par des URI.

Inconvénients

Les données nécessaires à l'utilisation du service web doivent être conservées localement.
Moins sûr que les architectures basées sur un protocole comme SOAP.

Références et ressources: Thèse de Roy-Fielding. Traduction du document qui a inspiré l'architecture REST. Original en anglais.