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]. Il trouve notamment des applications dans le World Wide Web.

Contraintes[modifier | modifier le code]

Une architecture REST doit respecter les six 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. À serveur sans état : chaque requête d'un client contient toute l'information nécessaire pour permettre au serveur de traiter la requête, sans dépendre d'un contexte conservé sur le serveur en relation avec des requêtes antérieures. Il n'y a pas de session entre le client et le serveur. Cela permet une plus grande visibilité sur la nature des interactions entre les composants, une plus grande robustesse face aux échecs et une plus grande disponibilité des ressources. En revanche, cela amène également une augmentation du trafic réseau et une baisse du contrôle du serveur sur l'application car il dépend alors de la mise en œuvre correcte de la sémantique de l'application par le client.
  3. Avec cache : chaque réponse d'un serveur contient un marquage explicite ou implicite de la possibilité ou non de la mettre en cache côté client ou côté serveur. Si une réponse peut être mise en cache, elle peut être réutilisée pour des requêtes ultérieures équivalentes. Cela permet des performances réseaux accrues car les clients ne font pas des requêtes inutilement lorsque la réponse est déjà présente dans le cache du client, et les serveurs ne traitent pas des requêtes inutilement lorsque la réponse est déjà présente dans le cache du serveur. En revanche, cela amène une baisse de fiabilité si les données en cache sont obsolètes.
  4. À interface uniforme :
    • identification des ressources : chaque ressource possède un identifiant ;
    • manipulation des ressources par des représentations : les ressources ont des représentations définies ;
    • messages auto-descriptifs : 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 ;
    • 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. Cela permet une plus grande simplicité de l'architecture globale, une meilleure visibilité des interactions entre les composants, un découplage des mises en œuvres et des services qu'elles fournissent. En revanche, cela amène aussi une perte d'efficacité car les interactions sont dans une forme normalisée au lieu d'être dans une forme spécifique aux besoins de l'application.
  5. En couches : chaque composant voit uniquement les composants de la couche avec laquelle il interagit directement. Cela permet une limitation de la complexité de l'architecture globale, une plus grande indépendance des couches, un renforcement de la sécurité et un équilibrage des charges sur les services. En revanche, cela amène un surcout et des performances réduites car les couches intermédiaires apportent une latence supplémentaire.
  6. Code à la demande (facultatif) : un serveur peut étendre les fonctionnalités d'un client en lui transférant du code exécutable. Par exemple des applets Java ou des scripts JavaScript. Cela permet de simplifier les clients en réduisant le nombre de fonctionnalités qu'ils doivent mettre en œuvre par défaut et améliore l'extensibilité du système. En revanche, cela réduit la visibilité de l'organisation des ressources. De ce fait, elle constitue une contrainte facultative dans une architecture REST.

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[2].

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[3]. Les APIs RESTful basées sur HTTP sont définies avec les aspects suivants[4] :

  • 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[4],: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[5].
  • les méthodes HTTP standard (par ex. : GET, POST, PUT, DELETE et OPTIONS)[6].

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[7]. 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ée. Généralement non utilisée. Elle Traite le membre adressé en tant que collection à part entière et crée une nouvelle entrée en son sein[7]. 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[8], 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[8].

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

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