Representational State Transfer

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher

REST (REpresentational State Transfer) 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[1].

REST n’est pas un protocole (tel que HTTP) ou un format. Ce style d'architecture est particulièrement bien adapté au World Wide Web mais n'en est pas dépendant. Les contraintes, telles que définies par Roy Fielding, peuvent s'appliquer à d'autres protocoles d'application que HTTP.

Contraintes d'une architecture REST[modifier | modifier le code]

Les contraintes sont les suivantes :

  1. 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.
  2. 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.
  3. 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.
  4. Une interface uniforme : cette contrainte agit selon 4 règles essentielles.
    1. L'identification des ressources : chaque ressource est identifiée uniquement
    2. La manipulation des ressources à travers des représentations : les ressources ont des représentations définies.
    3. 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.
    4. 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.
  5. Un système hiérarchisé par couche : les états de l'application sont identifiées 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.
  6. 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 contrainte[2].

Description de REST[modifier | modifier le code]

Confusion entre REST et protocoles[modifier | modifier le code]

Ce style architectural s'applique tout autant à la réalisation d’applications pour un utilisateur humain qu'à la réalisation d’architectures orientées services destinées à la communication entre machines.

RPC ainsi que SOAP ne sont pas des styles d'architecture mais des protocoles. Ces protocoles impliquent souvent des contraintes qui sont difficiles à rendre compatibles avec une architecture REST (Par exemple, la contrainte sur le système hiérarchisé ou l'interface uniforme). Les systèmes qui suivent les principes de l'architecture REST sont souvent appelés RESTful.

Avantages de REST[modifier | modifier le code]

La thèse de Roy Fielding précise les avantages de ce style architectural par rapport à d’autres styles d’architectures d’applications Web. Citons 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 en tirant 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 de REST[modifier | modifier le code]

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 d'électricité. La latence de la connexion rend également l'interaction moins fluide.

REST et HATEOAS[modifier | modifier le code]

Les termes REST et RESTful sont devenus des termes marketing pour rendre les services plus attractifs. Bien souvent, les services Web se réclamant de REST ne le sont pas. Tout au plus, ils appliquent le protocole HTTP de manière un peu plus conventionnelle. La communauté Web attachée aux principes de REST et la nature hypermedia des applications a décidé d'utiliser dorénavant le terme HATEOAS, qui est une abréviation pour Hypermedia as the Engine of Application State. Elle permet de rendre plus explicite une des contraintes essentielles de REST[3].

Nomenclature[modifier | modifier le code]

Le principal débat se concentre sur la pluralité ou non du nom d'entité. Par exemple, faut-il définir un service comme http://www.foo.com/Client ou http://www.foo.com/Clients. On retrouve les deux parmi les API les plus célèbres et les deux notations se valent. Que vous supportiez une école ou l'autre, l'important est de ne pas mélanger. Ainsi, si vous optez /Clients, l'unicité sera /Clients/abc et non pas /Client/abc. De plus, vous garderez la même convention pour l'ensemble des services de votre société.

Bibliographie[modifier | modifier le code]

  • RESTful Web Services, par Leonard Richardson et Sam Ruby, est un ouvrage en anglais sorti en mai 2007. Celui-ci a popularisé le style d’architecture REST[4].
  • Building Hypermedia APIs with HTML5 and Node, par Mike Amundsen, sorti en novembre 2011[5].
  • REST in Practice, par Jim Webber, Savas Parastatidis, Ian Robinson, sorti en septembre 2010[6].
  • REST API Design Rulebook, Designing Consistent RESTful Web Service Interfaces, par Mark Masse, sorti en octobre 2011[7].

Voir aussi[modifier | modifier le code]

Articles connexes[modifier | modifier le code]

Liens externes[modifier | modifier le code]

Notes et références[modifier | modifier le code]

  1. (fr) Thèse de Roy T. Fielding - Traduction du Chapitre 5 : REST
  2. (fr) Thèse de Roy T. Fielding - Traduction du Chapitre 5 : REST 5.2.1.1 Ressources et identifiants de ressource, 5.2.1.2 Représentations, 5.2.2 Connecteurs.
  3. (en) Roy T. Fielding, « REST APIs must be hypertext-driven »,‎ 20 Oct 2008 (consulté le 20 Mai 2010)
  4. (en) Leonard Richardson et Sam Ruby, RESTful Web Services, O'Reilly Media,‎ 2007, 454 p. (ISBN 978-0-596-52926-0)
  5. (en) Mike Amundsen, Building Hypermedia APIs with HTML5 and Node, O'Reilly Media,‎ 2011, 244 p. (ISBN 978-1-4493-0657-1)
  6. (en) Jim Webber, Savas Parastatidis et Ian Robinson, REST in Practice, O'Reilly Media,‎ 2010, 448 p. (ISBN 978-0-596-80582-1)
  7. (en) Mark Masse, REST API Design Rulebook, O'Reilly Media,‎ 2011, 116 p. (ISBN 978-1-4493-1050-9)