Representational state transfer

Un article de Wikipédia, l'encyclopédie libre.
(Redirigé depuis Rest)
Sauter à la navigation Sauter à la recherche

REST (Representational State Transfer) est un style d'architecture définissant un ensemble de contraintes et de propriétés basées sur le protocole HTTP. Les services web conformes au style d'architecture REST, aussi appelés services web RESTful, établissent une interopérabilité entre les ordinateurs sur Internet. Les services web REST permettent aux systèmes effectuant des requêtes d'accéder et de manipuler des représentations textuelles de ressources web à travers un jeu d'opérations uniformes et prédéfinies sans état. D'autres types de services web tels que les services web SOAP exposent leurs propres jeux d'opérations arbitraires[1].

Les « ressources web » ont été définies pour la première fois sur le World Wide Web comme des documents ou des fichiers identifiés par leur URL. Cependant, elles ont aujourd'hui une définition beaucoup plus générique et abstraite qui inclut toute chose ou entité pouvant être identifiée, nommée, adressée ou gérée d'une façon quelconque sur le web. Dans un service web REST, les requêtes effectuées sur l'URI d'une ressource produisent une réponse qui peut être en HTML, XML, JSON ou un autre format. La réponse confirme que la ressource stockée a été altérée et elle peut fournir des liens hypertextes vers d'autres ressources ou collection de ressources liées. Lorsque le protocole HTTP est utilisé, comme c'est souvent le cas, les opérations disponibles sont GET, POST, PUT, DELETE et d'autres méthodes HTTP CRUD.

Avec l'utilisation d'un protocole sans état et d'opérations standards, les systèmes REST visent la réactivité, la fiabilité et l'extensibilité, par la réutilisation de composants pouvant être gérés et mis à jour sans affecter le système global, même pendant son fonctionnement.

Le terme Representational State Transfer a été défini pour la première fois en 2000 par Roy Fielding dans le chapitre 5 de sa thèse de doctorat[2],[3],[4]. La thèse de Fielding a expliqué les principes de REST auparavant connus sous comme le « modèle objet de HTTP » depuis 1994 et qui ont été utilisé dans l'élaboration des standards HTTP 1.1 et URI. Le terme est censé évoquer comment une application web bien conçue se comporte : c'est un réseau de ressources (une machine à états virtuelle) au sein duquel l'utilisateur évolue en sélectionnant des liens, tels que /utilisateur/tom, et des opérations telles que GET ou DELETE (des transitions d'état), résultant dans le transfert de la ressources suivante (représentant le nouvel état de l'application) vers l'utilisateur pour être utilisée.

Histoire[modifier | modifier le code]

Roy Fielding à l'OSCON 2008.

Roy Fielding a défini REST en 2000 dans sa thèse de doctorat Architectural Styles and the Design of Network-based Software Architectures à l'université de Californie à Irvine[2]. Il y a développé le style d'architecture REST en parallèle du protocole HTTP 1.1 de 1996 à 1999, basé sur le modèle existant de HTTP 1.0 de 1996[5].

Lors d'un regard rétrospectif sur le développement de REST, Fielding a déclaré:

Throughout the HTTP standardization process, I was called on to defend the design choices of the Web. That is an extremely difficult thing to do within a process that accepts proposals from anyone on a topic that was rapidly becoming the center of an entire industry. I had comments from well over 500 developers, many of whom were distinguished engineers with decades of experience, and I had to explain everything from the most abstract notions of Web interaction to the finest details of HTTP syntax. That process honed my model down to a core set of principles, properties, and constraints that are now called REST.

— Roy Fielding, Discussion sur le développement de REST[5].

« Au cours de la procédure de standardisation de HTTP, on m'a appelé pour défendre les choix d'architecture du Web. C'est une tâche extrêmement compliquée dans la mesure où la procédure accepte les propositions de n'importe qui sur un sujet qui était en train de devenir rapidement le centre d'une industrie entière. Je recevais les commentaires de plus de 500 développeurs, dont de nombreux étaient des ingénieurs renommés avec des décennies d'expérience, et je devais tout expliquer, des notions les plus abstraites des interactions du Web jusqu'aux détails les plus subtils de la syntaxe de HTTP. Cette procédure a réduit mon modèle à un ensemble fondamental de principes, propriétés et contraintes qui sont aujourd'hui appelés REST. »

— Discussion sur le développement de REST[5].

Contraintes architecturales[modifier | modifier le code]

Six contraintes architecturales définissent un système REST[6],[7]. Ces contraintes restreignent la façon dont le serveur peut traiter et répondre aux requêtes du client afin que, en agissant dans ces contraintes, le service gagne des propriétés non fonctionnelles désirables, telles que la performance, l'extensibilité, la simplicité, l'évolutivité, la visibilité, la portabilité et la fiabilité[2]. Un système qui viole une de ces contraintes ne peut pas être considéré comme adhérant à l'architecture REST.

Client–serveur[modifier | modifier le code]

Article détaillé : Client–serveur.

Les responsabilités sont séparées entre le client et le serveur. Découpler l'interface utilisateur du stockage des données améliore la portabilité de l'interface utilisateur sur plusieurs plateformes. L'extensibilité du système se retrouve aussi améliorée par la simplification des composants serveurs. Mais peut-être encore plus essentiel pour le Web, la séparation permet aux composants d'évoluer indépendamment, supportant ainsi les multiples domaines organisationnels nécessaires à l'échelle d'Internet.

Sans état[modifier | modifier le code]

Article détaillé : Protocole sans état.

La communication client–serveur s'effectue sans conservation de l'état de la session de communication sur le serveur entre deux requêtes successives. L'état de la session est conservé par le client et transmis à chaque nouvelle requête. Les requêtes du client contiennent donc toute l'information nécessaire pour que le serveur puisse y répondre. La visibilité des interactions entre les composants s'en retrouve améliorée puisque les requêtes sont complètes. La tolérance aux échecs est également plus grande. De plus, le fait de ne pas avoir à maintenir une connexion permanente entre le client et le serveur permet au serveur de répondre à d'autres requêtes venant d'autres clients sans saturer l'ensemble de ses ports de communication, ce qui améliore l'extensibilité du système.

Cependant une exception usuelle à ce mode dit stateless est la gestion de l'authentification du client, afin que celui-ci n'ait pas à renvoyer ces informations à chacune de ses requêtes.

Avec mise en cache[modifier | modifier le code]

Article détaillé : Cache web.

Les clients et les serveurs intermédiaires peuvent mettre en cache les réponses. Les réponses doivent donc, implicitement ou explicitement, se définir comme pouvant être mise en cache ou non, afin d'empêcher les clients de récupérer des données obsolètes ou inappropriées en réponse à des requêtes ultérieures. Une mise en cache bien gérée élimine partiellement voire totalement certaines interactions client–serveur, améliorant davantage l'extensibilité et la performance du système.

En couches[modifier | modifier le code]

Article détaillé : Architecture en couches.

Un client ne peut habituellement pas dire s'il est connecté directement au serveur final ou à un serveur intermédiaire. Les serveur intermédiaires peuvent améliorer l'extensibilité du système en mettant en place une répartition de charge et un cache partagé. Ils peuvent aussi renforcer les politiques de sécurité.

Avec code à la demande (facultative)[modifier | modifier le code]

Les serveurs peuvent temporairement étendre ou modifier les fonctionnalités d'un client en lui transférant du code exécutable. Par exemple par 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 aussi la visibilité de l'organisation des ressources. De ce fait, elle constitue une contrainte facultative dans une architecture REST.

À interface uniforme[modifier | modifier le code]

La contrainte d'interface uniforme est fondamentale dans la conception de n'importe quel service REST. Elle simplifie et découple l'architecture, ce qui permet à chaque composant d'évoluer indépendamment. Les quatre contraintes de l'interface uniforme sont les suivantes.

Identification des ressources dans les requêtes[modifier | modifier le code]

Chaque ressource est identifiée dans les requêtes, par exemple par un URI dans le cas des systèmes REST basés sur le Web. Les ressources elles-mêmes sont conceptuellement distinctes des représentations qui sont retournées au client. Par exemple, le serveur peut envoyer des données de sa base de données en HTML, XML ou JSON, qui sont des représentations différentes de la représentation interne de la ressource.

Manipulation des ressources par des représentations[modifier | modifier le code]

Chaque représentation d'une ressource fournit suffisamment d'informations au client pour modifier ou supprimer la ressource.

Messages auto-descriptifs[modifier | modifier le code]

Chaque message contient assez d'information pour savoir comment l'interpréter. Par exemple, l'interpréteur à invoquer peut être décrit par un type de média.

Hypermédia comme moteur d'état de l'application (HATEOAS)[modifier | modifier le code]

Après avoir accédé à un URI initial de l'application — de manière analogue aux humains accédant à la page d'accueil d'une site web —, le client doit être en mesure d'utiliser dynamiquement les hyperliens fournis par le serveur pour découvrir toutes les autres actions possibles et les ressources dont il a besoin pour poursuivre la navigation. Il n'est pas nécessaire pour le client de coder en dur cette information concernant la structure ou la dynamique du service REST.

Propriétés architecturales[modifier | modifier le code]

Les contraintes architecturales de REST confèrent aux systèmes qui les respectent les propriétés architecturales suivantes[2],[6] :

  • performance dans les interactions des composants, qui peuvent être le facteur dominant dans la performance perçue par l'utilisateur et l'efficacité du réseau[8] ;
  • extensibilité permettant de supporter un grand nombre de composants et leurs interactions. Roy Fielding décrit l'effet de REST sur l'extensibilité comme suit :

REST's client–server separation of concerns simplifies component implementation, reduces the complexity of connector semantics, improves the effectiveness of performance tuning, and increases the scalability of pure server components. Layered system constraints allow intermediaries—proxies, gateways, and firewalls—to be introduced at various points in the communication without changing the interfaces between components, thus allowing them to assist in communication translation or improve performance via large-scale, shared caching. REST enables intermediate processing by constraining messages to be self-descriptive: interaction is stateless between requests, standard methods and media types are used to indicate semantics and exchange information, and responses explicitly indicate cacheability.

— Roy Fielding, Architectural Styles and the Design of Network-based Software Architectures[2].

« La séparation client–serveur des responsabilités simplifie l'implémentation des composants, réduit la complexité de la sémantique des connecteurs, améliore l'efficacité de l'optimisation des performances et augmente l'extensibilité des composants purement serveurs. La contrainte de système multicouches permet aux intermédiaires — serveurs mandataires, passerelles et pares-feu — d'être introduits à différents niveaux dans la communication sans changer les interfaces entre les composants, leur permettant ainsi d'intervenir dans la traduction des communications ou d'améliorer les performances via des systèmes de cache à grande échelle. REST permet les traitement intermédiaire en forçant des messages auto-descriptifs : l'interaction est sans état entre les requêtes, les méthodes standards et les types de média sont utilisés pour indiquer la sémantique et échanger l'information, et les réponses indiquent explicitement la possibilité de la mise en cache. »

— Architectural Styles and the Design of Network-based Software Architectures[2].

  • simplicité d'une interface uniforme ;
  • évolutivité des composants pour répondre aux besoins (même lorsque l'application est en cours de fonctionnement) ;
  • visibilité des communications entre les composants par des agents de service ;
  • portabilité des composants en déplaçant le code avec les données ;
  • fiabilité dans la résistance aux pannes du système en cas de pannes des composants, des connecteurs ou des données[8].

Appliqué aux services web[modifier | modifier le code]

Les API REST basées sur HTTP sont définies par[7] :

  • une URL de base, comme http://api.example.com/resources/ ;
  • un type de média pour les données permettant une transition d'état (par ex. : Atom, microformats, application/vnd.collection+json, etc.). La nature hypermédia de l'application permet d'accéder aux états suivants de l'application par inspection de la représentation courante. Cela peut être aussi simple qu'une URL ou aussi complexe qu'un applet Java ;
  • des méthodes HTTP standards (par ex. : GET, POST, PUT, DELETE et OPTIONS).

Relation entre URL et 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 REST :

Méthodes HTTP
URL GET PUT POST DELETE
Collection, telle que http://api.exemple.com/ressources/ Liste les URI 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[9]. 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[9]. 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.

Contrairement aux services web orientés SOAP, il n'y a pas de norme officielle pour les API REST[10], parce que REST est une architecture alors que SOAP est un protocole. REST n'est pas une norme en soi, mais les implémentations qui suivent cette architecture utilisent des normes comme HTTP, URI, JSON et XML[10].

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

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. (en) « Web Services Architecture », sur W3, (consulté le 6 mai 2018)
  2. a, b, c, d et e (en) Roy Thomas Fielding, Architectural Styles and the Design of Network-based Software Architectures, Irvine, université de Californie à Irvine, , 162 p. (lire en ligne), chap. 5 (« Representational State Transfer (REST) »)
  3. « Thèse de Roy T. Fielding - Traduction du Chapitre 5 : REST », sur Opikanoba, (consulté le 10 mai 2018)
  4. (en) « Fielding discute de la définition du terme REST », sur Yahoo, (consulté le 10 mai 2018)
  5. a et b (en) « Discussion sur le développement de REST » [archive du ], sur Yahoo, (consulté le 10 mai 2018)
  6. a et b (en) Thomas Erl, Benjamin Carlyle, Cesare Pautasso et Raj Balasubramanian, SOA with REST : Principles, Patterns & Constraints for Building Enterprise Solutions with REST, Upper Saddle River, New Jersey, Prentice Hall, , 624 p. (ISBN 978-0-13-701251-0), chap. 5.1
  7. a et b (en) Leonard Richardson et Sam Ruby, RESTful Web Services, Sebastopol, Californie, O'Reilly Media, , 446 p. (ISBN 978-0-596-52926-0)
  8. a et b (en) Roy Thomas Fielding, Architectural Styles and the Design of Network-based Software Architectures, Irvine, université de Californie à Irvine, , 162 p. (lire en ligne), chap. 2 (« Network-based Application Architectures »)
  9. a et b (en) Jeremy H, « API Example Using REST », sur There Is No Right Way, (consulté le 31 juillet 2014)
  10. a et b (en) « Learn REST: A Tutorial », sur Elkstein, (consulté le 13 mai 2018)
  11. (en) Leonard Richardson et Sam Ruby, RESTful Web Services, O'Reilly Media, , 454 p. (ISBN 978-0-596-52926-0)
  12. (en) Mike Amundsen, Building Hypermedia APIs with HTML5 and Node, O'Reilly Media, , 244 p. (ISBN 978-1-4493-0657-1)
  13. (en) Jim Webber, Savas Parastatidis et Ian Robinson, REST in Practice, O'Reilly Media, , 448 p. (ISBN 978-0-596-80582-1)
  14. (en) Mark Masse, REST API Design Rulebook, O'Reilly Media, , 116 p. (ISBN 978-1-4493-1050-9)