|
SOAP
Créé sous les hospices de Microsoft et toujours soutenu par
ce dernier, le protocole SOAP se montre bien plus populaire
et utilisé que son camarade XML-RPC - principalement grâce
au soutient du W3C, mainteneur de la spécification depuis
la version 1.2 du protocole, publiée en 2003. De fait, aujourd'hui,
SOAP est un standard de facto du monde des services Web :
un service se doit d'être au moins accessible par ce protocole.
Voici un exemple de requête SOAP, pour le service Google.
L'appel de procédure est indiqué en gras :
<?xml version='1.0' encoding='UTF-8'?>
<s:Envelope
xmlns:s="http://www.w3.org/2001/06/soap-envelope"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<s:Body>
<x:FlickrRequest xmlns:x="urn:flickr">
<method>flickr.echo</method>
<name>value</name>
</x:FlickrRequest>
</s:Body>
</s:Envelope>
Les données renvoyées sont elles-mêmes au format SOAP :
<?xml version="1.0" encoding="utf-8"
?>
<s:Envelope
xmlns:s="http://www.w3.org/2001/06/soap-envelope"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<s:Body>
<x:FlickrResponse xmlns:x="urn:flickr">
<method>flickr.test.echo</method>
<format>soap</format>
<foo>bar</foo>
<api_key>78ce850f064baa9e7fc7128794989563</api_key>
</x:FlickrResponse>
</s:Body>
</s:Envelope>
Les
protocoles RPC ont leur place et leur usage, mais ne font
souvent que compliquer les choses. SOAP est considéré comme
trop compliqué, et XML-RPC comme pas assez complet. Les deux
sont pourtant largement implémentés dans les systèmes d'aujourd'hui.
Ces deux protocoles utilisent uniquement la méthode POST du
protocole HTTP, là où dans de nombre cas l'utilisation REST
ne requiert qu'un GET.
REST
L'architecture REST n'est pas un protocole en soi, ni une
technologie, mais une "philosophie" de l'utilisation du Web.
Le protocole utilisé ici est simplement HTTP avec ses méthodes
(GET, POST et les autres
). Cette philosophie estime qu'il
n'est, dans bien des cas, pas nécessaire de faire appel aux
couches d'abstraction proposées par SOAP et XML-RPC, et que
les méthodes de HTTP, combinées avec de bonne URIs, suffisent
amplement dans la majorité des cas.
Voici un exemple de requête de type REST, tel qu'utilisée
par le service Flickr :
http://www.flickr.com/services/rest/?method=flickr.echo
&name=value
Et la réponse :
<?xml version="1.0" encoding="utf-8"
?>
<rsp stat="ok">
<method>flickr.test.echo</method>
<format>rest</format>
<foo>bar</foo>
<api_key>cc5eb7cce4f7e5bb39c259a63e6e9215</api_key>
</rsp>
 |
Forum |
|
|
Réagissez
dans les forums
de JDN Développeurs
|
Conclusion
Il est facile, par les trois exemples proposés par un même
service Web, de voir que la méthode la plus simple est REST,
qui a l'avantage énorme de ne pas ajouter une couche d'abstraction
à des données qui n'en ont pas forcément besoin.
Mais aujourd'hui, tous les langages modernes disposent de
fonctionnalités leur permettant d'exploiter des services Web
type SOAP ou XML-RPC sans se soucier de la verbosité de leurs
messages sortants et entrants. C'est d'ailleurs la raison
pour laquelle ces deux techniques ont tant de succès vis-à-vis
de REST : les outils sont disponibles, tandis que REST nécessite
de mettre en place ses propres méthodes (même si le protocole,
lui existe déjà).
De SOAP ou XML-RPC, le choix des développeurs tend à se porter
sur la première méthode, du fait de certains défauts dans
la spécification de la seconde : manque de précisions, confusions
sur certains aspects (support Unicode, notamment), mots de
passe transmis en clair
XML-RPC reste un format très utilisé par de nombreux développeurs,
et est largement implémenté. La meilleure direction à prendre
lors de la construction d'un service Web serait bien entendu
d'implémenter les trois, mais en l'état actuel des choses,
les méthodes à implémenter sont REST pour la simplicité, et
SOAP pour le support (Microsoft/W3C). XML-RPC semble ne plus
être qu'un bonus donné aux développeurs qui ne souhaite pas
manipuler ces deux autres méthodes.
|
