Representational State Transfer

REST (REpresentational State Transfer) est un style

darchitecture pour les systmes hypermdia distribus,
cr par Roy Fielding en 2000 dans le chapitre 5 de sa
thse de doctorat
[1]
.
REST nest pas un protocole (tel que HTTP) ou un
format. Ce style d'architecture est particulirement bien
adapt au World Wide Web mais n'en est pas dpen-
dant. Les contraintes, telles que dnies par Roy Fielding,
peuvent sappliquer d'autres protocoles d'application
que HTTP.
1 Contraintes d'une architecture
REST
Les contraintes sont les 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 per-
met 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 ser-
veur. Cela libre de nombreuses interactions entre
le client et le serveur.
3. Mise en cache : le serveur envoie une rponse qui
donne l'information sur la propension de cette r-
ponse tre mise en cache, comme la fracheur, sa
date de cration, si elle doit tre conserve dans le
futur. Cela permet des serveurs mandataires de d-
charger les contraintes sur le serveur et aux clients de
ne pas faire de requtes inutiles. Cela permet gale-
ment d'amliorer l'extensibilit des serveurs.
4. Une interface uniforme : cette contrainte agit selon
4 rgles essentielles.
(a) L'identication des ressources : chaque res-
source est identie unitairement
(b) La manipulation des ressources travers des
reprsentations : les ressources ont des repr-
sentations dnies.
(c) Un message auto-descriptif : les messages ex-
pliquent leur nature. Par exemple, si une re-
prsentation en HTML est code en UTF-8,
le message contient l'information ncessaire
pour dire que c'est le cas.
(d) 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 couche : les tats
de l'application sont identies par des ressources
individuelles. Toute l'information n'est pas en-
voye dans une seule ressource unique. Les re-
qutes/rponses entre le client et le serveur aug-
mentent et donc peuvent faire baisser la perfor-
mance d'o l'importance de la mise en cache, etc.
Le bnce est que cela rend beaucoup plus exible
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 dpen-
dant du client et non plus du serveur ce qui contredit
la rgle 2. Il faut donc tre prudent en utilisant cette
contrainte
[2]
.
2 Description de REST
2.1 Confusion entre REST et protocoles
Ce style architectural sapplique tout autant la ralisa-
tion dapplications pour un utilisateur humain qu' la ra-
lisation darchitectures 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 diciles 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.
2.2 Avantages de REST
La thse de Roy Fielding prcise les avantages de ce style
architectural par rapport dautres styles darchitectures
1
2 4 VOIR AUSSI
dapplications Web. Citons entre autres :
Lapplication est plus simple entretenir, car elle d-
solidarise la partie client de la partie serveur. La na-
ture 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 de-
vient essentiel dans un systme distribu.
Labsence 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 dun loadbalancer), ou propager sur tous
les serveurs (avec des problmatiques de fracheur
de session). Cela permet aussi une meilleure volu-
tivit et tolrance aux pannes (un serveur peut tre
ajout facilement pour augmenter la capacit de trai-
tement, ou pour en remplacer un autre).
Dans un contexte Web
--- lutilisation du protocole HTTP en tirant parti
de son enveloppe et ses en-ttes.
--- lutilisation dURI comme reprsentant dune
ressource permet d'avoir un systme universel
d'identication des lments de l'application.
--- la nature auto-descriptive du message permet
la mise en place de serveurs cache. Les in-
formations ncessaires sur la fracheur, la p-
remption de la ressource sont contenues dans
le message lui-mme
2.3 Inconvnients de REST
Le principal inconvnient de REST est la ncessit pour
le client de conserver localement toutes les donnes n-
cessaires au bon droulement dune requte, ce qui induit
une consommation en bande passante rseau plus grande.
Notamment dans l'univers des appareils mobiles, chaque
aller-retour de connexion est consommateur d'lectricit.
La latence de la connexion rend galement l'interaction
moins uide.
2.4 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 hyper-
media des applications a dcid d'utiliser dornavant le
terme HATEOAS, qui est une abrviation pour Hyper-
media as the Engine of Application State. Elle permet de
rendre plus explicite une des contraintes essentielles de
REST
[3]
.
2.5 Nomenclature
Le principal dbat se concentre sur la pluralit ou non
du nom d'entit. Par exemple, faut-il dnir un service
comme http://www.foo.com/Client ou http://www.foo.
com/Clients. On retrouve les deux parmi les API les plus
clbres et les deux notations se valent. Que vous sup-
portiez une cole ou l'autre, l'important est de ne pas
mlanger. Ainsi, si vous optez /Clients, l'unicit sera
/Clients/abc et non pas /Client/abc. De plus, vous garde-
rez la mme convention pour l'ensemble des services de
votre socit.
3 Bibliographie
RESTful Web Services, par Leonard Richardson et
Sam Ruby, est un ouvrage en anglais sorti en mai
2007. Celui-ci a popularis le style darchitecture
REST
[4]
.
Building Hypermedia APIs with HTML5 and Node,
par Mike Amundsen, sorti en novembre 2011
[5]
.
REST in Practice, par Jim Webber, Savas Parastati-
dis, Ian Robinson, sorti en septembre 2010
[6]
.
REST API Design Rulebook, Designing Consistent
RESTful Web Service Interfaces, par Mark Masse,
sorti en octobre 2011
[7]
.
4 Voir aussi
4.1 Articles connexes
World Wide Web
Hypertext Transfer Protocol
Protocole Waka
Roy Fielding
4.2 Liens externes
(en) Architectural Styles and the Design of Network-
based Software Architectures La thse de Roy Fiel-
ding dans laquelle il dcrit larchitecture REST
3
(fr) Thse de Roy T. Fielding - Traduction du Cha-
pitre 5 : REST
(fr) Tutoriel pour un Web Service crit avec JSP
(fr) Web Services : JBoss privilgie lapproche
REST
(en) howto rest pour AOLserver, PyWX, Quixote
(en) JBoss Helps Developers RESTEasy Writing
REST-based Java Web Services
5 Notes et rfrences
[1] (fr) Thse de Roy T. Fielding - Traduction du Chapitre 5 :
REST
[2] (fr) Thse de Roy T. Fielding - Traduction du Chapitre
5 : REST 5.2.1.1 Ressources et identiants de ressource,
5.2.1.2 Reprsentations, 5.2.2 Connecteurs.
[3] (en) Roy T. Fielding, REST APIs must be hypertext-
driven , 20 Oct 2008 (consult le 20 Mai 2010)
[4] (en) Leonard Richardson et Sam Ruby, RESTful Web
Services, O'Reilly Media, 2007, 454 p. (ISBN978-0-596-
52926-0)
[5] (en) Mike Amundsen, Building Hypermedia APIs with
HTML5 and Node, O'Reilly Media, 2011, 244 p. (ISBN
978-1-4493-0657-1)
[6] (en) Jim Webber, Savas Parastatidis et Ian Robinson,
REST in Practice, O'Reilly Media, 2010, 448 p. (ISBN
978-0-596-80582-1)
[7] (en) Mark Masse, REST API Design Rulebook, O'Reilly
Media, 2011, 116 p. (ISBN 978-1-4493-1050-9)
Portail de linformatique
4 6 SOURCES, CONTRIBUTEURS ET LICENCES DU TEXTE ET DE LIMAGE
6 Sources, contributeurs et licences du texte et de limage
6.1 Texte
Representational State Transfer Source : http://fr.wikipedia.org/wiki/Representational_State_Transfer?oldid=106201357 Contribu-
teurs : Jerome misc, Benoitb, Marc Mongenet, KarlDubost, Carmine, Keriluamox, Jef-Infojef, Sbrunner, Vincnet, Pramette, Elg, Streetpc,
FlaBot, YurikBot, LeonardoRob0t, Goulu, Bortzmeyer, Passoa15, Flo, Toutoune25, Neokilly, Nicorama, Georoy.aubry, Sylenius, B
a l a k, MetalGearLiquid, Manudwarf, Genium, Jujun, Stephane.lecorne, S.dubourg, Bahanix, Thijs !bot, Flying jacket, Flrt, Ftier-
cel, Jerome.guillaume, Yannick56, Yves Dubugnon, Footix, Speculos, Vincent Lextrait, TXiKiBoT, Aproche, VolkovBot, Sulletf, Xa-
vier.Chatelain, AlleborgoBot, DavidBourguignon, Dhatier, GLec, Mdeby, HerculeBot, LaaknorBot, Trizek, Luckas-bot, ArthurBot, Xq-
bot, RibotBOT, JackBot, LucienBOT, Touam, Candyghost, Lomita, Echartre, Grobh, J2PIf, EmausBot, Fractaliste, Httqm, WikitanvirBot,
Addbot et Anonyme : 45
6.2 Images
Fichier:Crystal_mycomputer.png Source : http://upload.wikimedia.org/wikipedia/commons/e/e3/Crystal_mycomputer.png Licence :
LGPL Contributeurs : All Crystal icons were posted by the author as LGPL on kde-look Artiste dorigine : Everaldo Coelho (YellowIcon)
6.3 Licence du contenu
Creative Commons Attribution-Share Alike 3.0