Representational state transfer

Un article de Wikipédia, l'encyclopédie libre.
(Redirigé depuis REST)
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]. Il trouve notamment des applications dans le World Wide Web.

Contraintes[modifier | modifier le code]

Une architecture REST doit respecter les contraintes 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 : toute réponse du serveur comprend des indications quant à la possibilité de mettre en cache cette réponse, comme sa fraîcheur, sa date de création, sa validité future. 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 quatre règles essentielles :
    1. l'identification des ressources : chaque ressource est identifiée unitairement ;
    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 encodé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 couches : 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.
  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[modifier | modifier le code]

Assimilation à un protocole ou un format[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. 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 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[évasif]. 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.

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 : http://www.foo.com/Client ou http://www.foo.com/Clients.

L'important est de ne pas mélanger en suivant une seule et même convention au sein d'un projet.

Appliqué aux webservices[modifier | modifier le code]

Les APIs de services web qui adhèrent aux contraintes de l'architecture REST sont appelés RESTful APIs[4]. Les APIs RESTful basées sur HTTP sont définies avec les aspects suivants[5] :

  • l'URL de base, comme http://api.example.com/resources/
  • le Type MIME qui définit des éléments de donnée de transition d'état[pas clair] (par ex. : Atom, microformats, application/vnd.collection+json[5],:91–99 etc.). La représentation courante avertit le client sur la manière de composer une requête de transition vers chacun des autres états possibles de l'application. Cela peut être aussi simple qu'une URL ou aussi complexe qu'un applet java[6].
  • les méthodes HTTP standard (par ex. : OPTIONS, GET, PUT, POST, and DELETE)[7]

Relation entre l'URL et les méthodes HTTP[modifier | modifier le code]

Le tableau suivant affiche la manière avec laquelle les méthodes HTTP sont utilisées dans une API RESTful :

Méthodes HTTP
URL GET PUT POST DELETE
Collection, telle que http://api.exemple.com/ressources/ Liste les URIs et peut-être d'autres détails des membres de la collection. Remplace la collection entière par une autre collection. Crée une nouvelle entrée dans la collection. L'URI de la nouvelle entrée est assignée automatiquement et est retournée par cette opération[8]. Supprime l'entière collection.
Élément, tel que http://api.exemple.com/ressources/item17 Récupérer une représentation du membre adressé de la collection, exprimé dans un type de média Internet approprié. Remplace le membre adressé de la collection, ou s'il n'existe pas, le créer. Généralement non utilisée. Elle Traite le membre adressé en tant que collection à part entière et créer une nouvelle entrée en son sein[8]. Supprime le membre adressé de la collection.

La méthode GET est sûre (en anglais, on peut dire nullipotent), c'est-à-dire qu'elle n'a pas d'effet de bord : ni la recherche ni l'accès ne modifient l'enregistrement. Les méthodes PUT et DELETE sont idempotentes, c'est-à-dire que la répétition d'une même requête ne change pas l'état du système exposé par l'API.

Contrairement aux services Web orientés SOAP, il n'y a pas de norme "officielle" pour les APIs RESTful[9], parce que REST est une architecture alors que SOAP est un protocole. REST n'est pas une norme en soi, mais les implantations RESTful utilisent des normes comme HTTP, URI, JSON et XML[9].

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[10].
  • Building Hypermedia APIs with HTML5 and Node, par Mike Amundsen, sorti en novembre 2011[11].
  • REST in Practice, par Jim Webber, Savas Parastatidis, Ian Robinson, sorti en septembre 2010[12].
  • REST API Design Rulebook, Designing Consistent RESTful Web Service Interfaces, par Mark Masse, sorti en octobre 2011[13].

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 », (consulté le 20 mai 2010)
  4. (en) « What is REST API », sur RESTful API Tutorial (consulté le 29 septembre 2016)
  5. a et b « {{{1}}} »
  6. (en) Roy T. Fielding, « REST APIs must be hypertext driven », roy.gbiv.com, (consulté le 6 juillet 2016)
  7. Modèle:Cite IETF
  8. a et b (en) Jeremy H, « API Example Using REST », sur There Is No Right Way, (consulté le 31 juillet 2014)
  9. a et b (en) M Elkstein, « Learn REST: A Tutorial », blogger.com, (consulté le 16 avril 2015)
  10. (en) Leonard Richardson et Sam Ruby, RESTful Web Services, O'Reilly Media, , 454 p. (ISBN 978-0-596-52926-0)
  11. (en) Mike Amundsen, Building Hypermedia APIs with HTML5 and Node, O'Reilly Media, , 244 p. (ISBN 978-1-4493-0657-1)
  12. (en) Jim Webber, Savas Parastatidis et Ian Robinson, REST in Practice, O'Reilly Media, , 448 p. (ISBN 978-0-596-80582-1)
  13. (en) Mark Masse, REST API Design Rulebook, O'Reilly Media, , 116 p. (ISBN 978-1-4493-1050-9)