REST est une architecture de services Web, à la manière de SOAP et de XML-RPC. C'est l'acronyme de REpresentational State Transfer. Elaboré en l'an 2000 par Roy Fielding, l'un des créateurs du protocole HTTP, du serveur Apache HTTPd et d'autres travaux fondamentaux, REST est à l'origine une tentative de décrire les principes de l'architecture du Web.
Cette architecture part du principe selon lequel Internet est composé de ressources accessibles à partir d'une URL. Par exemple, pour avoir le temps à Paris, un utilisateur pourrait utiliser une adresse de la forme http://www.meteo.fr/paris/ : Paris serait alors une ressource telle que définie par Météo France.
A la requête de cet URL serait renvoyée une représentation de la ressource demandée (paris.php, par exemple). Cette représentation place l'application cliente dans un état (state) donné.
Si l'application cliente lance un appel sur un des liens de la représentation en cours, une autre ressource est appelée, dont une représentation est envoyée. Ainsi, l'application cliente change d'état (state transfer) pour chaque représentation de ressource.
Il faut bien noter que REST n'est pas en soi un standard : il n'existe pas de spécification du W3C pour la décrire. Il s'agit plutôt d'un style d'architecture, d'un "mode de compréhension du Web" sur lequel le développeur construit ses services (Web).
REST fait en revanche usage des standards Web : protocole HTTP, URLs, formats de fichiers pour la représentation des ressources (XML, HTML, JPEG...), types MIME pour la description de ces représentations... Le Web lui-même est d'ailleurs un système REST à part entière.
Un service "RESTful" ("reposé" ou "tranquille") se distingue largement d'un service SOAP ou XML-RPC en cela qu'il repose uniquement sur l'utilisation d'HTTP, des URIs et d'XML, là où les deux autres protocoles se compliquent la tâche en utilisant des API RPC (Remote Procedure Call, appel de procédure distante). SOAP et XML-RPC ne suivent pas la spécification HTTP, car ils ajoutent une nouvelle couche d'abstraction par-dessus le protocole, plutôt que de l'utiliser tel qu'il a été conçu. De même, leur utilisation des URIs n'est pas idéale...
Simplement, REST part du principe selon lequel HTTP suffit largement à l'ensemble des besoins d'un service Web, pour peu qu'on utilise l'ensemble des méthodes de ce protocole : GET, POST, mais aussi PUT, DELETE, CONNECT...
Pour résumer, là où SOAP et XML-RPC se basent sur des méthodes, REST se base sur les ressources existantes.
Un service RESTful
Voyons comment construire et utiliser un service suivant le style REST.
Un service REST devrait respecter les "conventions" suivantes :
- toutes les ressources devant être exposées au travers du service doivent être correctement identifiées, et de manière unique. Chaque ressource devra se voir assigner une URL. Qui plus est, l'URL en question devra être de la forme http://www.site.com/contenus/1789 plutôt que http://www.site.com/contenus.php?id=1789.
- les ressources doivent être catégorisées selon leurs possibilités offertes à l'application cliente : ne peut-elle que recevoir une représentation (GET) ou peut-elle modifier/créer une ressource (POST, PUT, DELETE) ?
- chaque ressource devrait faire un lien vers les ressources liées.
- la manière dont fonctionne le service sera décrite au sein d'un document WSDL, ou simplement HTML.
Prenons une entreprise de jouets qui veut permettre à ses clients 1) d'obtenir une liste des jouets disponibles à la vente, 2) d'obtenir des informations sur un jouet précis.
1) La liste des jouets est disponible à l'URL suivante :
http://www.youpilesjouets.com/jouets/
La manière dont le service génère cette liste n'est pas important pour le client : tout ce qu'il sait, c'est que cette adresse lui renverra la liste. La société est donc libre de modifier la manière dont la liste est générée, tant qu'elle l'est. C'est le principe du "couplage lâche" (loose coupling).
Le client reçoit une réponse sous la forme suivante :
[...]
La liste des jouets contient des liens pour obtenir des informations sur chaque jouet. C'est là la clef de REST : le lien entre les ressources. Le client peut ensuite choisir parmi les liens proposés pour aller plus loin.
2) Les détails d'un jouet se trouvent à l'URL :
http://www.youpilesjouets.com/jouets/00002/
Ce qui renvoi la réponse :
A nouveau, plus de ressources sont accessibles grâce à un lien...
