REST API

Representational State Transfer

REST est un style d'architecture pour les systèmes hypermédia distribués, créé par Roy Fielding en 2000 dans le chapitre 5 de sa thèse de doctorat.

Contraintes

Une architecture REST doit respecter les contraintes suivantes :

• Client-serveur : les responsabilités sont séparées entre le client et le serveur. L'interface utilisateur est séparée de celle du stockage des données. Cela permet aux deux d'évoluer indépendamment.
• Sans état : chaque requête d'un client vers un serveur doit contenir toute l'information nécessaire pour permettre au serveur de comprendre la requête, sans avoir à dépendre d'un contexte conservé sur le serveur. Cela libère de nombreuses interactions entre le client et le serveur.
• Mise en cache : le serveur envoie une réponse qui donne l'information sur la propension de cette réponse à être mise en cache, comme la fraîcheur, sa date de création, si elle doit être conservée dans le futur. Cela permet à des serveurs mandataires de décharger les contraintes sur le serveur et aux clients de ne pas faire de requêtes inutiles. Cela permet également d'améliorer l'extensibilité des serveurs.
• Une interface uniforme ; cette contrainte agit selon quatre règles essentielles :
• l'identification des ressources : chaque ressource est identifiée unitairement ;
• la manipulation des ressources à travers des représentations : les ressources ont des représentations définies ;
• un message auto-descriptif : les messages expliquent leur nature. Par exemple, si une représentation en HTML est codée en UTF-8, le message contient l'information nécessaire pour dire que c'est le cas ;
• hypermédia comme moteur d'état de l'application : chaque accès aux états suivants de l'application est décrit dans le message courant.
• Un système hiérarchisé par couche : les états de l'application sont identifiés par des ressources individuelles. Toute l'information n'est pas envoyée dans une seule ressource unique. Les requêtes/réponses entre le client et le serveur augmentent et donc peuvent faire baisser la performance d'où l'importance de la mise en cache, etc. Le bénéfice est que cela rend beaucoup plus flexible l'évolution du système.
• Code-on-demand (facultatif) : la possibilité pour les clients d’exécuter des scripts obtenus depuis le serveur. Cela permet d'éviter que le traitement ne se fasse que du côté serveur et permet donc de faire évoluer les fonctionnalités du client au cours du temps. En revanche cela réduit la visibilité de l'organisation des ressources. Un état devient dépendant du client et non plus du serveur ce qui contredit la règle 2. Il faut donc être prudent en utilisant cette contrainte2.

Avantages

La thèse de Roy Fielding précise les avantages de ce style architectural par rapport à d'autres styles d’architectures d'applications Web. Entre autres :

• L'application est plus simple à entretenir, car elle désolidarise la partie client de la partie serveur. La nature hypermédia de l'application permet d'accéder aux états suivants de l'application par inspection de la ressource courante.
• L'absence de gestion d’état du client sur le serveur conduit à une plus grande indépendance entre le client et le serveur. Elle permet également de ne pas avoir à maintenir une connexion permanente entre le client et le serveur. Le serveur peut ainsi répondre à d'autres requêtes venant d'autres clients sans saturer l'ensemble de ses ports de communication. Cela devient essentiel dans un système distribué.
• L'absence de gestion d’état du client sur le serveur permet également une répartition des requêtes sur plusieurs serveurs : une session client n’est pas à maintenir sur un serveur en particulier (via une sticky session d'un loadbalancer), ou à propager sur tous les serveurs (avec des problématiques de fraîcheur de session). Cela permet aussi une meilleure évolutivité et tolérance aux pannes (un serveur peut être ajouté facilement pour augmenter la capacité de traitement, ou pour en remplacer un autre).
• Dans un contexte Web :
• l'utilisation du protocole HTTP permet de tirer parti de son enveloppe et ses en-têtes ;
• l'utilisation d'URI comme représentant d'une ressource permet d'avoir un système universel d'identification des éléments de l'application ;
• la nature auto-descriptive du message permet la mise en place de serveurs cache : les informations nécessaires sur la fraîcheur, la péremption de la ressource sont contenues dans le message lui-même.

Inconvénients

Le principal inconvénient de REST est la nécessité pour le client de conserver localement toutes les données nécessaires au bon déroulement d’une requête, ce qui induit une consommation en bande passante réseau plus grande. Notamment dans l'univers des appareils mobiles, chaque aller-retour de connexion est consommateur de bande passante. La latence de la connexion rend également l'interaction moins fluide.