Representational state transfer

REST (representational state transfer) est un style d'architecture pour les systmes hypermdia distribus,
cr par Roy Fielding en 2000 dans le chapitre 5 de sa thse de doctorat 1. Il trouve notamment des applications
dans le World Wide Web.

Sommaire
1 Contraintes
2 Description
2.1 Assimilation un protocole ou un format
2.2 Avantages de REST
2.3 Inconvnients de REST
2.4 REST et HATEOAS
2.5 Nomenclature
3 Appliqu aux webservices
3.1 Relation entre l'URL et les mthodes HTTP
4 Bibliographie
5 Voir aussi
5.1 Articles connexes
5.2 Liens externes
6 Notes et rfrences

Contraintes
Une architecture REST doit respecter les contraintes suivantes :

1. Client-serveur : les responsabilits sont spares entre le client et le serveur. L'interface utilisateur est
spare de celle du stockage des donnes. Cela permet aux deux d'voluer indpendamment.
2. Sans tat : chaque requte d'un client vers un serveur doit contenir toute l'information ncessaire pour
permettre au serveur de comprendre la requte, sans avoir dpendre d'un contexte conserv sur le
serveur. Cela libre de nombreuses interactions entre le client et le serveur.
3. Mise en cache : toute rponse du serveur comprend des indications quant la possibilit de mettre en
cache cette rponse, comme sa fracheur, sa date de cration, sa validit future. Cela permet des
serveurs mandataires de dcharger les contraintes sur le serveur et aux clients de ne pas faire de requtes
inutiles. Cela permet galement d'amliorer l'extensibilit des serveurs.
4. Une interface uniforme ; cette contrainte agit selon quatre rgles essentielles :
1. l'identification des ressources : chaque ressource est identifie unitairement ;
2. la manipulation des ressources travers des reprsentations : les ressources ont des reprsentations
dfinies ;
3. un message auto-descriptif : les messages expliquent leur nature. Par exemple, si une
reprsentation en HTML est encode en UTF-8, le message contient l'information ncessaire pour
dire que c'est le cas ;
4. hypermdia comme moteur d'tat de l'application : chaque accs aux tats suivants de l'application
est dcrit dans le message courant.
5. Un systme hirarchis par couches : les tats de l'application sont identifis par des ressources
individuelles. Toute l'information n'est pas envoye dans une seule ressource unique. Les
requtes/rponses entre le client et le serveur augmentent et donc peuvent faire baisser la performance
d'o l'importance de la mise en cache, etc. Le bnfice est que cela rend beaucoup plus flexible
l'volution du systme.
 6. Code-on-demand (facultatif) : la possibilit pour les clients dexcuter des scripts obtenus depuis le
serveur. Cela permet d'viter que le traitement ne se fasse que du ct serveur et permet donc de faire
voluer les fonctionnalits du client au cours du temps. En revanche cela rduit la visibilit de
l'organisation des ressources. Un tat devient dpendant du client et non plus du serveur ce qui contredit
la rgle 2. Il faut donc tre prudent en utilisant cette contrainte 2.

Description
Assimilation un pr otocole ou un format

Ce style architectural s'applique tout autant la ralisation d'applications pour un utilisateur humain qu' la
ralisation d'architectures orientes services destines la communication entre machines.

RPC ainsi que SOAP ne sont pas des styles d'architecture mais des protocoles. Ces protocoles impliquent
souvent des contraintes qui sont difficiles rendre compatibles avec une architecture REST (par exemple, la
contrainte sur le systme hirarchis ou l'interface uniforme). Les systmes qui suivent les principes de
l'architecture REST sont souvent appels RESTful.

Avantages de REST

La thse de Roy Fielding prcise les avantages de ce style architectural par rapport d'autres styles
darchitectures d'applications Web. Entre autres :

L'application est plus simple entretenir, car elle dsolidarise la partie client de la partie serveur. La nature
hypermdia de l'application permet d'accder aux tats suivants de l'application par inspection de la ressource
courante.
L'absence de gestion dtat du client sur le serveur conduit une plus grande indpendance entre le client et
le serveur. Elle permet galement de ne pas avoir maintenir une connexion permanente entre le client et le
serveur. Le serveur peut ainsi rpondre d'autres requtes venant d'autres clients sans saturer l'ensemble de
ses ports de communication. Cela devient essentiel dans un systme distribu.
L'absence de gestion dtat du client sur le serveur permet galement une rpartition des requtes sur
plusieurs serveurs : une session client nest pas maintenir sur un serveur en particulier (via une sticky
session d'un loadbalancer), ou propager sur tous les serveurs (avec des problmatiques de fracheur de
session). Cela permet aussi une meilleure volutivit et tolrance aux pannes (un serveur peut tre ajout
facilement pour augmenter la capacit de traitement, ou pour en remplacer un autre).
Dans un contexte Web :
l'utilisation du protocole HTTP permet de tirer parti de son enveloppe et ses en-ttes ;
l'utilisation d'URI comme reprsentant d'une ressource permet d'avoir un systme universel d'identification
des lments de l'application ;
la nature auto-descriptive du message permet la mise en place de serveurs cache : les informations
ncessaires sur la fracheur, la premption de la ressource sont contenues dans le message lui-mme.

Inconvnients de REST

Le principal inconvnient de REST est la ncessit pour le client de conserver localement toutes les donnes
ncessaires au bon droulement dune requte, ce qui induit une consommation en bande passante rseau plus
grande [vasif]. Notamment dans l'univers des appareils mobiles, chaque aller-retour de connexion est
consommateur de bande passante. La latence de la connexion rend galement l'interaction moins fluide.

REST et HATEOAS

Les termes REST et RESTful sont devenus des termes marketing pour rendre les services plus attractifs. Bien
souvent, les services Web se rclamant de REST ne le sont pas. Tout au plus, ils appliquent le protocole HTTP
de manire un peu plus conventionnelle. La communaut Web attache aux principes de REST et la nature
hypermedia des applications a dcid d'utiliser dornavant le terme HATEOAS, qui est une abrviation pour
hypermedia as the engine of application state. Elle permet de rendre plus explicite une des contraintes
essentielles de REST 3.

Nomenclature

Le principal dbat se concentre sur la pluralit ou non du nom d'entit.

Par exemple : http://www.foo.com/Client ou http://www.foo.com/Clients.

L'important est de ne pas mlanger en suivant une seule et mme convention au sein d'un projet.

Appliqu aux webservices

Les APIs de services web qui adhrent aux contraintes de l'architecture REST sont appels RESTful APIs 4. Les
APIs RESTful bases sur HTTP sont dfinies avec les aspects suivants 5 :

l'URL de base, comme http://api.example.com/resources/

le Type MIME qui dfinit des lments de donne de transition d'tat[pas clair] (par ex. : Atom, microformats,
5 :9199
application/vnd.collection+json , etc.). La reprsentation courante avertit le client sur la manire de
composer une requte de transition vers chacun des autres tats possibles de l'application. Cela peut tre aussi
simple qu'une URL ou aussi complexe qu'un applet java 6.
les mthodes HTTP standard (par ex. : OPTIONS, GET, PUT, POST, and DELETE) 7

Relation entre l'URL et les mth odes HTTP

Le tableau suivant affiche la manire avec laquelle les mthodes HTTP sont utilises dans une API RESTful :

Mthodes HTTP
URL GET PUT POST DELETE
Cre une nouvelle
Remplace entre dans la
Liste les URIs
la collection. L'URI
et peut-tre Supprime
Collection, telle que collection de la nouvelle
d'autres dtails l'entire
http://api.exemple.com/ressources/ entire par entre est assigne
des membres collection.
une autre automatiquement et
de la collection.
collection. est retourne par
8
cette opration .
Rcuprer une Remplace
Gnralement non
reprsentation le membre
utilise. Elle Traite
du membre adress de Supprime
le membre adress
adress de la la le membre
lment, tel que en tant que
collection, collection, adress de
http://api.exemple.com/ressources/item17 collection part
exprim dans ou s'il la
entire et crer une
un type de n'existe collection.
nouvelle entre en
mdia Internet pas, le 8
son sein .
appropri. crer.

La mthode GET est sre (en anglais, on peut dire nullipotent), c'est--dire qu'elle n'a pas d'effet de bord : ni la
recherche ni l'accs ne modifient l'enregistrement. Les mthodes PUT et DELETE sont idempotentes, c'est--
dire que la rptition d'une mme requte ne change pas l'tat du systme expos par l'API.

9
Contrairement aux services Web orients SOAP, il n'y a pas de norme "officielle" pour les APIs RESTful 9,
parce que REST est une architecture alors que SOAP est un protocole. REST n'est pas une norme en soi, mais
les implantations RESTful utilisent des normes comme HTTP, URI, JSON et XML 9.

Bibliographie
RESTful Web Services, par Leonard Richardson et Sam Ruby, est un ouvrage en anglais sorti en mai 2007.
10
Celui-ci a popularis le style darchitecture REST .
11
Building Hypermedia APIs with HTML5 and Node, par Mike Amundsen, sorti en novembre 2011 .
12
REST in Practice, par Jim Webber, Savas Parastatidis, Ian Robinson, sorti en septembre 2010 .
REST API Design Rulebook, Designing Consistent RESTful Web Service Interfaces, par Mark Masse, sorti
en octobre 2011 13.

Voir aussi
Articles connexes

Protocole Waka

Liens externes

(en) Architectural Styles and the Design of Network-based Software Architectures La thse de Roy Fielding
dans laquelle il dcrit larchitecture REST
Thse de Roy T. Fielding - Traduction du Chapitre 5 : REST
Tutoriel pour un Web Service crit avec JSP
Web Services : JBoss privilgie lapproche REST
(en) howto rest pour AOLserver, PyWX, Quixote
(en) JBoss Helps Developers RESTEasy Writing REST-based Java Web Services

Notes et rfrences
1. (fr) Thse de Roy T . Fielding - T raduction du Chapitre 5 : REST (http://opikanoba.or g/tr/fielding/rest/)
2. (fr) Thse de Roy T . Fielding - T raduction du chapitre 5 : REST (http://opikanoba.or g/tr/fielding/rest/) 5.2.1.1
Ressources et identifiants de ressource, 5.2.1.2 Reprsentations, 5.2.2 Connecteurs.
3. (en) Roy T. Fielding, REST APIs must be hypertext-driven (http://roy.gbiv.com/untangled/2008/rest-apis-must-be-h
ypertext-driven) , 20 octobre 2008 (consult le 20 mai 2010 )
4. (en) What is REST API (http://restfulapi.net/) , sur RESTful API T utorial (consult le 29 septembre 2016 )
5. {{{1}}}
6. (en) Roy T. Fielding, REST APIs must be hypertext driven (http://roy.gbiv.com/untangled/2008/rest-apis-must-be-h
ypertext-driven) , roy.gbiv.com, 20 octobre 2008 (consult le 6 juillet 2016 )
7. Modle:Cite IETF
8. (en) Jeremy H, API Example Using REST (http://thereisnorightway .blogspot.com/2012/05/api-example-using-rest.
html), sur There Is No Right Way, 16 mai 2012 (consult le 31 juillet 2014 )
9. (en) M Elkstein, Learn REST: A Tutorial (http://rest.elkstein.or g/2008/02/what-is-rest.html) , blogger.com,
fvrier 2008 (consult le 16 avril 2015 )
10. (en) Leonard Richardson et Sam Ruby, RESTful Web Services , O'Reilly Media, 2007, 454 p.
(ISBN 978-0-596-52926-0 )
11. (en) Mike Amundsen , Building Hypermedia APIs with HTML5 and Node , O'Reilly Media, 2011, 244 p.
(ISBN 978-1-4493-0657-1 )
12. (en) Jim Webber, Savas Parastatidis et Ian Robinson , REST in Practice , O'Reilly Media, 2010, 448 p.
(ISBN 978-0-596-80582-1 )
13. (en) Mark Masse, REST API Design Rulebook , O'Reilly Media, 2011, 116 p. (ISBN 978-1-4493-1050-9 )
Ce document provient de https://fr.wikipedia.org/w/index.php?
title=Representational_state_transfer&oldid=137642756 .

Cette page a t modifie pour la dernire fois le 25 mai 2017 07:01.

Droit d'auteur : les textes sont disponibles sous licence Creative Commons attribution, partage dans les mmes
conditions ; dautres conditions peuvent sappliquer. Voyez les conditions dutilisation pour plus de dtails,
ainsi que les crdits graphiques. En cas de rutilisation des textes de cette page, voyez comment citer les
auteurs et mentionner la licence.
Wikipedia est une marque dpose de la Wikimedia Foundation, Inc., organisation de bienfaisance rgie par
le paragraphe 501(c)(3) du code fiscal des tats-Unis.