Je ne connaissais pas cet usage de REST...
Il existe une specification basée sur REST pour les appels de procédure distante ?
xml-rpc blah blah blah
Je soupçonne les concepteurs de la spécification XML-RPC d'avoir oeuvré en fonction des limitations de leur propre implémentation initiale... Je travaille en ce moment sur une librairie en php et je trouve le format assez torturé.
Par nature le XML est un format bavard puisqu'on retrouve le nom de chaque element dans le tag de fermeture, alors qu'avec ses règles strictes d'imbrication un simple </> aurait suffi. De plus, les concepteurs de dialecte XML sont souvent des gens un poil anxieux qui multiplient les éléments, je ne sais pas trop pourquoi.
Mais alors le xml-rpc, c'est franchement le bordel. Bon, il y a de quoi vouloir etre prevoyant puisqu'il s'agit d'un language générique pour faire des appels de procedure distante. (par exemple, les fameux ping et trackback des blogs). Mais quand je vois :
<?xml version="1.0"?>
<methodResponse>
<fault>
<value>
<struct>
<member>
<name>faultCode</name>
<value><int>4</int></value>
</member>
<member>
<name>faultString</name>
<value><string>Too many parameters.</string></value>
</member>
</struct>
</value>
</fault>
</methodResponse>
Au lieu de, par exemple, ça :
<?xml version="1.0"?>
<methodResponse>
<fault>
<code>4</code>
<desc>Too many parameters.</desc>
</fault>
</methodResponse>
Je me dis que la volonté initiale de simplicité s'est un peu perdue en route... J'ai du mal à comprendre cette volonté de se passer totalement d'attributs et d'intercaler des éléments inutiles comme le <data> entre un <array> et les <value>. Le pire, c'est encore le type des <value> qui est un élément s'intercalant entre l'élément et son contenu, et optionnel avec ça !!! Il aurait été tellement plus logique d'utiliser un attribut. Pfff...
jabber
Le SOAP c'est un peu le même genre, c'est pour ca que le REST 'est pas mal à la mode en se moment. Ca utilise les GET POST PUT du protocole http tous en permettant de faire des interfaces poussé