Cet article a pour objectif de présenter les architectures REST : REpresentational State Transfer. Il s’agit là d’une introduction dont le but est de présenter ses concepts de base, le sujet pouvant aisément faire l’objet d’un livre de 600 pages !

REST
Concepts

REST signifie REpresentational State Transfer. Ce terme a été inventé il y a une dizaine d’années par Roy Fielding, l’un des auteurs principaux de la spécification du protocole HTTP. Pour bien comprendre ce que signifie ce sigle, expliquons d’abord les concepts qu’il renferme.

Pour comprendre REST, il ne faut pas voir le Web comme un ensemble de pages mais comme un ensemble de ressources accessibles à partir d’une URI (Uniform Resource Identifier). Par exemple, une URI de la forme suivante permettrait à un utilisateur de connaître le détail du contrat n°12345 :

http://.../contrats/12345/

L’utilisateur qui effectuerait cette requête avec son client obtiendrait donc une représentation de la ressource « contrat n°12345 ». Cette représentation peut être un document HTML, un document XML, une image, etc.

En fait, la représentation demandée positionne le client utilisé par l’utilisateur dans un certain état. Cette représentation propose des liens vers d’autres représentations de ressources. Si l’utilisateur clique sur un de ces liens, il obtient une nouvelle représentation d’une ressource : son client change d’état et c’est ce principe qui donne son nom à REST.

Caractéristiques

Dans le chapitre 6 de sa thèse, Fielding résume ainsi l’objectif principal de REST :

“The name “Representational State Transfer” is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through the application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use.”

En fait, REST n’est pas une technologie, c’est un style d’architectures. Des architectures de services Web, dans le sens premier du terme : des services pour le Web. Et REST n’est pas un standard bien qu’il soit lui-même basé sur des standards :

• Protocole : HTTP ;
• Formats de représentation des ressources : XML, HTML, GIF, JPEG…
• Description des formats de représentation des ressources : types MIME.

On notera simplement que le protocole HTTP (HyperText Transfer Protocol) propose uniquement 8 opérations sur les ressources (dont les plus connues sont : GET, POST, PUT et DELETE). Par exemple, un utilisateur souhaitant connaître le détail du contrat n°12345 devra envoyer une requête HTTP de la forme suivante :

GET http://.../contrats/12345/

Toutes les applications reposant sur de tels principes bénéficient donc de la même interface et l’architecture est plus extensible. Ce point a joué un rôle majeur dans le succès du Web : si chaque application avait sa propre API, il n’y aurait eu tous ces millions de sites !

De REST aux ROA…

Notion de ROA

Un nouveau terme a été inventé pour désigner les architectures reposant sur les principes évoqués précédemment : les ROA, ou Resource Oriented Architectures. Comme leur nom l’indique, il s’agit d’architectures focalisées sur les ressources, qui sont alors décrites et structurées.

Dans ce type d’architectures, on dispose donc d’un nombre fixé et standardisé d’opérations simples, qui peuvent être appliquées sur des ressources variées. On est très proche du design pattern Memento : un fournisseur de services gère un ensemble de ressources et expose un ensemble d’opérations basiques (de type CRUD) :

• De création : requête POST ;
• De récupération : requête GET ;
• De modification : requête PUT ;
• De suppression : requête DELETE.

Positionnement des ROA

Les architectures ROA sont souvent opposées aux architectures RPC, ou Remote Procedure Call : dans ce type d’architectures, chaque application possède une API composée d’opérations plus spécifiques et souvent plus complexes que celles proposées par le protocole HTTP.

Il s’agit donc d’architectures focalisées sur les opérations et non plus sur les ressources : ce n’est plus le protocole HTTP qui définit les opérations, il ne sert plus qu’au transport de messages reposant sur des opérations spécifiques et non standard. La couche Réseau est alors masquée par une couche RPC et la sémantique HTTP n’est plus exploitée directement. C’est le cas de SOAP par exemple.

On parle également d’architectures orientées activités car elles sont focalisées sur les actions possibles plutôt que sur les ressources sur lesquelles elles agissent : on est cette fois-ci plus proche des design patterns Command ou Proxy.

Naturellement, les architectures ROA bénéficient des avantages de REST : simplicité de mise en œuvre, facilité d’intégration des technologies du Web et capacité de montée en charge notamment. Un autre intérêt par rapport aux architectures RPC est que REST n’impose qu’un couplage faible entre les composants : les architectures RPC induisent au contraire un fort couplage puisque les structures de données échangées sont projetées côté client et côté serveur. Ceci rend plus difficiles la gestion des évolutions et de la maintenance des systèmes d’information.

Critères de choix

Dès lors, comment choisir entre une architecture orientée ressources et une architecture orientée activités ?

L’effet de mode autour de REST ainsi que les arguments soulevés précédemment soulignent sa simplicité et sa souplesse par rapport à des solutions basées sur SOAP par exemple. Il ne faut cependant pas tirer de conclusions aussi hâtivement car tout dépend des besoins.

Le premier critère, nous l’avons vu, est le profil de l’application : doit-elle se focaliser sur les ressources ou sur les actions ?

Viennent ensuite d’autres critères, dans le domaine des services techniques proposés. Par exemple, on peut citer les quelques inconvénients de REST suivants :

• Le protocole HTTP n’est pas fiable : il ne garantit pas la bonne transmission des messages ;
• Le protocole HTTP n’apporte pas plus de fonctionnalités de routage que celles proposées par les proxies HTTP basiques ;
• Le protocole HTTP est très limité en matière de sécurité ;
• Le protocole HTTP n’est pas extensible (on ne peut y ajouter d’opération) et ne propose pas de format de description de services (comme le WSDL pour SOAP).

On constate ici un point important : ce qui est un avantage de REST dans un contexte A peut devenir un inconvénient dans un contexte B, et inversement. Il est donc très important de bien situer le contexte et de ne pas se laisser emmener par l’effet de mode : une fois de plus, tout dépend des besoins.

Précisons toutefois que rien n’empêche la mise en place de tels services techniques dans une architecture basée sur REST : ils ne sont pas (encore) standardisés mais peuvent tout à fait être utilisés. L’inverse est également possible : ainsi le format WSDL permet tout à fait la description de services REST et non SOAP.

Un peu de recul : conception d’une architecture ROA

Dans ce qui précède, nous sommes partis du principe qu’une architecture ROA est simplement une architecture reposant sur les principes REST. En fait, REST est à la fois très simple et très vague : en pratique, on considérera qu’une architecture ROA se compose d’un ensemble de règles et de bonnes pratiques REST.

Voici à titre d’exemple quelques principes communément retenus :

• Chaque élément d’intérêt de l’application, abstrait ou concret, doit être représenté par une ressource et donc une URI ;
• Les URI doivent être descriptives et même prévisibles ;
• Les représentations des ressources doivent contenir des données, mais également des liens qui les connectent via leur URI ;
• Les services doivent être sans état : chaque requête effectuée doit embarquer toutes les informations nécessaires (cela permet en outre de ne pas provoquer de comportement anormal avec le bouton « Back » du navigateur et même de faciliter la mise en place de load balancing). Attention : l’utilisation de cookies et de sessions est une violation de ce principe puisqu’alors le serveur connaît l’état du client et peut adapter sa réponse en fonction ;
• Une politique de cache doit être mise en place : les réponses doivent pouvoir être marquées comme pouvant être mises en cache ou non.

Pour en savoir plus

Architectural Styles and the Design of Network-based Software Architectures, R. Fielding :
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

RESTful Web Services, L. Richardson et S. Ruby (O’Reilly) :
http://www.oreilly.com/catalog/9780596529260/

Softies on Rails – REST 101 :
http://softiesonrails.com/tags/rest

Resource-oriented vs. activity-oriented Web services, J. Snell (IBM)
http://www-128.ibm.com/developerworks/webservices/library/ws-restvsoap/

François Goldgewicht

Tags: internet, rest

This entry was posted on Friday, October 12th, 2007 at 9:06 am and is filed under Architecture, Intégration. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.