xml decid : Stratégies, marchés, affaires autour de XML.
[xml-decid] Re: WS : REST / SOAP
From: JP Moresmau (jean-philippe.moresmau@soamai.com)
Date: 13/02/2003 - 10:59
Derrière le nom un peu barbare de REST se cachent des principes assez
simples: en fait, REST est une théorisation de certains principes du Web,
mis en form by Roy T. Fielding, un des concepteurs du protocol HTTP. Sa
dissertation (http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm)
explique en détail de quoi il s'agit.
En gros, REST dit que toutes les opérations effectués via le web n'utilisent
qu'un certain nombre d'opérations: des opérations de lecture (via la méthode
HTTP GET) de mise à jour (PUT), d'ajout de données (POST) et de suppression
(DELETE). Utiliser un nombre réduit d'opérations défini dans un protocole
permet de facilement reconnaitre les messages: si je "vois" une requete HTTP
GET, je sais qu'il va s'agir d'une lecture de donnée qui va sans doute
pouvoir être cachée par un intermédiaire, par exemple. De plus REST indique
que chaque "chose" sur le web qui est accessible (REST parle de resource)
doit avoir une URI: un nom unique qui permet de l'identifier, et, dans la
plupart des cas, de s'y connecter.
Dans le cadre des Web Services, les supporters de REST disent: REST nous
donne tout ce dont nous avons besoin, pourquoi s'embêter avec SOAP? La vraie
intéropérabilité des Web Services n'est pas SOAP, c'est le fait que les
données échangées soient transmises dans un format bien défini, c'est à dire
XML. On n'obtient une intéropérabilité équivalent, sinon meilleure, avec
REST: un web service est representé par une URL et, eventuellement, des
informations qui indiquerait quel type de données passer à ce service. SOAP
ne vous dispense pas non plus de cette phase là, elle est juste simplifiée
par la présence d'outils qui font la translation entre SOAP et la
représentation dans un langage de programmation des données échangées. Il
est très facile d'avoir des services web qui n'utilisent pas SOAP en ayant
ces outils de translation, par exemple pour transformer du Java en XML.
REST ne vous force pas à utiliser XML: si vous voulez implémenter un service
web qui renvoit une image, en SOAP vous êtes obligé soit d'encoder l'image
en XML, soit de l'attacher au message SOAP. En REST, pour pouver renvoyer
l'image via HTTP en indiquant dans l'entête qu'il s'agit d'une image. De
même, le client peut indiquer au service quelles types de données il
comprend, de la même manière que votre navigateur indique aux sites sur
lesquels vous surfez qu'il comprend le HTML, le PDF, les images GIF, etc...
Autrement dit, avec REST vous pouvez passer toutes les données que vous
voulez sans avoir à les forcer à les faire entrer dans le format SOAP, d'où
un gain important en simplicité et en performance.
Conceptuellement, REST est plus difficile à saisir que SOAP (qui n'est qu'un
protocole de RPC en XML) mais permet de fait des web services en utilisant
la recette qui a permis au Web de rencontrer le succès que l'on sait. Mais
il est à craindre que les grands joueurs de l'industrie du logiciel poussent
SOAP et les autres standards, de plus en plus complexes et de moins en moins
Web, pour vendre plus de leurs logiciels... La simplicité ne peut pas se
vendre cher...
Si vous maitrisez l'anglais, vous trouvere plus d'infos sur
http://conveyor.com/RESTwiki/moin.cgi
JP
Soamaï Jean-Philippe Moresmau - CTO-Directeur Technique 1025 rue Henri
Becquerel - 34036 Montpellier cedex 01 - FRANCE Tél : +33(0)4 99 52 65 43 -
Mob : +33(0)6 72 75 21 27 Std : +33 (0)1 46 08 69 00 - Fax : +33(0)1 46 08
69 51 www.soamai.com
----- Original Message -----
From: "Thierry - listes" <thgalist@natapassion.com>
To: <xml-decid@xmlfr.org>
Sent: Thursday, February 13, 2003 11:25 AM
Subject: [xml-decid] WS : REST / SOAP
>
> Bonjour,
>
> Au sujet des Web Sevices (WS), j'ai quelques questions.
>
> Un des avantages d'avoir une norme comme SOAP est qu'un certain nombre
d'outils de
> génération et de parsing automatique existe maintenant.
> Par exemple, si je veux faire communiquer d'un côté du PHP avec le package
nusoap
> et de l'autre côté du Java avec Axis, en principe cela ne pose pas de
soucis et la
> tâche du développeur en est grandement facilitée : quelques lignes à
écrire pour
> appeler ces composants, tant en utilisation cliente qu'en déploiement de
WS.
>
> SOAP est portable partout, je crois que c'est ça qu'on appelle
l'interopérabilité.
>
> En ce qui concerne, l'architecture REST existe-t-il des possibilités
similaires ou
> serions-nous condamnés à tout réécrire à chaque développement ?
> Depuis peu, le site de Sun fait mention de l'architecture REST comme
n'étant pas à
> négliger ; il donne l'origine du nom : "Representational State Transfer".
Que cela
> signfie-t-il ? Qu'est-ce que cela recouvre ?
>
> Quels sont les avantages et les inconvénients de REST par rapport à SOAP ?
> Je n'arrive toujours pas à comprendre en quoi l'architecture REST permet
un
> couplage plus lâche que SOAP. De toutes façon le client et le serveur
doivent
> comprendre le même langage XML ; n'est-ce pas ?
>
> bye - Cdlt,
>
> Thierry GAGNAIRE
> mailto:thga@tgagnaire.com
>
>
>
> --
> Devenez redacteur <XML>fr et contribuez au developpement
> du xml francophone (http://xmlfr.org/infos/redacteurs) !
>
> Liste de diffusion "xml-decid@xmlfr.org" (http://xmlfr.org).
>
> Cette liste est a votre disposition pour discuter en francais de
> tout sujet lie a XML.
>
> Pour resilier votre abonnement, envoyez un message contenant la
> commande "unsubscribe" a xml-decid-request@xmlfr.org
> (mailto:xml-decid-request@xmlfr.org?Subject=unsubscribe)
>
--
Devenez redacteur <XML>fr et contribuez au developpement
du xml francophone (http://xmlfr.org/infos/redacteurs) !
Liste de diffusion "xml-decid@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de
tout sujet lie a XML.
Pour resilier votre abonnement, envoyez un message contenant la
commande "unsubscribe" a xml-decid-request@xmlfr.org
(mailto:xml-decid-request@xmlfr.org?Subject=unsubscribe)
Archive générée par hypermail 2.1.3 le 28/02/2003 - 08:02 UTC
webmaster@xmlfr.org
|
