Representational State Transfer

REST (Representational State Transfer) est une manière de construire une application pour les systèmes distribués comme le World Wide Web. Le terme a été inventé par Roy Fielding en 2000.

REST n’est pas un protocole ou un format, c’est un style d’architecture, c’est le style architectural original du Web.

Dans cette architecture, un composant lit ou modifie une ressource en utilisant une représentation de cette ressource. Une ressource est une chose nommable, qui peut évoluer avec le temps. Une représentation est une séquence d’octets, éventuellement accompagnée de métadonnées (séquence de nom/valeur). Un composant est un acteur, il est relié à d’autres composants et à des ressources par des canaux, qui permettent des interactions sans états^[1].

L’application de cette architecture au Web se comprend sur quelques principes simples :

• l’URI est important : connaître l’URI doit suffire pour nommer et identifier une ressource^[2] ;
• HTTP fournit toutes les opérations nécessaires (GET, POST, PUT et DELETE, essentiellement) ;
• chaque opération est auto-suffisante : il n’y a pas d’état ;
• utilisation des standards hypermedia : HTML ou XML qui permettent de faire des liens vers d’autres ressources et d’assurer ainsi la navigation dans l’application REST sont souvent utilisés. Néanmoins, l’utilisation d’autres formats comme JSON ou autres est possible.

Description de REST

Ce style architectural n’est pas limité à la réalisation d’application pour un utilisateur humain. Il est de plus en plus utilisé pour la réalisation d’architectures orientées services utilisant des services Web destinés à la communication entre machines. REST se pose en alternative au style architectural RPC et à la plupart des cas d’utilisation de SOAP (bien que l’on puisse imaginer des architectures orientées services de style REST mais utilisant la technologie SOAP), alternative censée être plus simple à mettre en œuvre. Les systèmes qui suivent les principes REST de Fielding sont souvent appelés RESTful.

Il met en avant la différence entre l’état du client (navigateur, ou bibliothèque cliente du web service), et l’état de l’application (ou état des ressources maintenues par le serveur).

Même si les réponses aux requêtes sont, comme pour SOAP et XML-RPC, souvent en XML, cela n’a rien d’obligatoire. Des réponses JSON ou en objets Java sérialisés sont parfaitement acceptables.

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. Citons entre autres :

• L’application est plus simple à entretenir, car les liens sont mieux structurés, et de façon universelle ; les liens sont le moteur de l’état de l’application.
• L’absence de gestion d’état du client sur le serveur conduit à une consommation de mémoire inférieure, une plus grande simplicité et donc à une capacité plus grande de répondre à un grand nombre de requêtes simultanées.
• L’absence de gestion d’état du client sur le serveur permet 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).
• L’utilisation du protocole HTTP en tirant partie de son enveloppe et ses entêtes, à l’opposé de SOAP qui ne présuppose pas un protocole : SOAP réinvente un protocole via une enveloppe, des entêtes et un document, à l’intérieur du protocole réseau l’hébergeant (la plupart du temps HTTP). il ne bénéficie donc pas des caractéristiques HTTP, gérée par l’infrastructure réseau (notamment les proxy supportant le cache côté serveur pour des performances plus importantes).
• L’utilisation d’URI comme représentant d’une ressource, permet la mise en place de serveurs cache.

Inconvénients

Les principaux inconvénients de REST sont 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. S’il est possible de coupler une application web REST à un service extérieur assurant la permanence des données lors de la durée d’une session, par exemple une base de données ou un cookie, on pourrait cependant considérer que l’utilisation d’un tel service pour gérer des données relatives à une session ouverte par le client serait en violation de la philosophie de REST. REST préfèrera l’utilisation de tableaux codés en Javascript présents dans la mémoire du navigateur client.

L’utilisation d’un formulaire HTML envoyant ses données avec une méthode comme DELETE ne peut être compris par la plupart des navigateurs. Pour pallier ce problème on émule ce comportement avec un champ caché qui transmettra le type de méthode d’envoi des données à l’application.

Par ailleurs beaucoup d’applications, bien que ne respectant pas scrupuleusement toutes les contraintes de l’architecture REST, sont largement inspirées par elle.

Bibliographie

• 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^{[réf. souhaitée]}.

Voir aussi

Articles connexes

• World Wide Web
• Hypertext Transfer Protocol
• Protocole Waka
• Roy Fielding
• Exemple d'utilisation : Ruby on Rails

Liens externes

• (en) Architectural Styles and the Design of Network-based Software Architectures La thèse de Roy Fielding dans laquelle il décrit l’architecture REST
• (fr) Thèse de Roy T. Fielding - Traduction du Chapitre 5 : REST
• (fr) Tutoriel pour un Web Service écrit avec JSP
• (fr) Web Services : JBoss privilégie l’approche REST
• (en) howto rest pour AOLserver, PyWX, Quixote
• (en) JBoss Helps Developers RESTEasy Writing REST-based Java Web Services

Notes et références

• Portail de l’informatique