Services Web XML:Accéder à un service Web
Un article de WikiTuto.
Sommaire |
Il existe plusieurs formats concurrents pour définir le format de données en entrée et sortie d'un service Web. Nous allons aborder XML-RPC et, plus récent, SOAP.
XML Remote Procedure Calling - XML-RPC
Principe
- sur le poste client, une bibliothèque encode les paramètres de la requête en XML ;
- sur le poste serveur, une (autre) bibliothèque les décode et les transmet à l'application.
La procédure inverse a lieu lors de l'envoi de la réponse à la requête vers le poste client. En définitive, le programmeur n'a jamais besoin de coder lui-même le format de sortie en XML, puisque, dans le cadre du langage de programmation qu'il utilise, des fonctions se chargent des opérations à sa place. Il n'en voit que le résultat final.
Le transfert des données se fait selon le protocole HTTP.
Il existe des bibliothèques en Perl, C, Python, Java, |VB.net, PHP...
Exemple et limitations
Par exemple, Adam's Names, qui est une sorte de "WhoIs" pour les sites hébergés dans plusieurs îles du Pacifique, utilise ce protocole.
Le système a malheureusement des limites. En théorie, par exemple, les seuls transferts autorisés se font sous le format ASCII, même si des extensions -non officielles- autorisent les transferts en Unicode. De plus, ce format n'est pas normalisé par un organisme indépendant et neutre (comme le W3C).
Simple Object Access Protocol - SOAP
Principe
Il s'agit du protocole actuellement le plus en vogue -il est promu par le W3C lui-même et Microsoft, et la première recommandation date de juin 2003.
Le principe est le même : le programmeur ne voit jamais le fichier XML que son poste émet ou reçoit, car tout est géré par une bibliothèque de fonctions et procédures dont il ne perçoit que le résultat final, avec le format habituel de son langage de programmation favori.
Des bibliothèques SOAP existent pour Perl, C, C#, Python, Java, VB/.Net, PHP, même Ada...
SOAP permet d'utiliser le même typage de données que celui des schémas XML, des tableaux, des structures... bref, il est plus complet (et donc plus complexe...) que XML-RPC.
Exemple et limitations
L'exemple suivant illustre une requête SOAP simple, demandant à un serveur si un code postal est valable dans le Royaume Uni :
<env.Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope"> <env.Body> <m:ValidatePostcodeResponse m:env:encodingStyle="http://www.w3.org/2001/06/soap-encoding" xmlns:m="http://www.lesiteduserviceweb.com/Postcode"> <PostCode>WC1A8GH</PostCode> <Country>UK</Country> </m:ValidatePostcodeResponse > </env.Body> </env.Envelope>
En réponse, le serveur enverra le même type d'"enveloppe" ; mais le corps du message (<env:Body>) se limitera à l'élément <Valid>Yes</Valid>.
Une des limitations principales de ce format est, par sa nature XML, son côté "usine à gaz".
Sources
Voir aussi
- Généralités
- Trouver un service Web
- Accéder à un service Web
- Récapitulation et inconvénients



