Representational state transfer

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). Une 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.

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 dans ce cas là 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.

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 .

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.
• L'absence d'état sur le serveur conduit à une consommation de mémoire inférieure et donc à une capacité plus grande de répondre à un grand nombre de requêtes simultanées.
• L'absence d'état sur le serveur rend le fonctionnement plus simple à appréhender. Le résultat d'une requête ne dépend pas de variables cachées difficilement identifiables. Cela conduit à une mise au point plus simple.
• L'absence d'état sur le serveur permet une répartition des requêtes sur plusieurs serveurs avec une meilleure granularité et de manière plus souple. Cela permet aussi une meilleure tolérance aux pannes d'un des serveurs.
• Le respect de la philosophie du protocole HTTP (à la différence de la manière dont est habituellement utilisé SOAP) conduit à une architecture plus cohérente et plus simple.
• 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, et le manque à gagner des capacités du serveur. 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.

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.

Implémentation

• Python RIP
• Ruby On Rails Rails
• Java Restlet
• Java Jboss RESTEasy
• PHP Symfony
• .NET 3.5: ADO.NET Data Services (ex-Astoria)

Voir aussi

Articles connexes

• World Wide Web
• Hypertext Transfer Protocol
• Protocole Waka
• Roy Fielding

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

1. ↑ (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
2. ↑ (en) URI/Resource Relationships (Relations URI / Ressources), dans Architecture of the World Wide Web, W3C Recommendation 15 December 2004

Ce document provient de « Representational State Transfer ».