TUTORIELS 
L'architecture REST

Page 1 | 2

Manière de représenter la logique de l'Internet, REST définit également des bonnes pratiques de création de service Web, tout en simplifiant leur élaboration par l'utilisation de standards historiques.
 (7 juillet 2003)
 

Qu'est-ce que REST ?
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.

Page 1 | 2

 
[ Xavier Borderie,JDNet
 
Accueil | Haut de page