Com­mu­ni­quer dans des réseaux comme Internet peut uni­que­ment fonc­tion­ner si l’on se base sur des règles précises. Afin de garantir que les dif­fé­rents or­di­na­teurs et d’autres appareils com­pa­tibles avec le réseau ne sombrent pas dans le chaos, ils doivent observer un protocole réseau. Avec REST, SOAP est l’un des prin­ci­paux pro­to­coles sur Internet.

Qu’est-ce que SOAP ?

La com­mu­ni­ca­tion sur Internet est en principe basée sur des pro­to­coles tels que HTTP, HTTPS, FTP ou – à un autre niveau – TCP. SOAP est toutefois uni­que­ment utilisé pour les services Web. Il s’agit d’une interface per­met­tant à un appareil d’utiliser le service d’un serveur. Les moteurs de recherche, les boutiques en ligne et de nombreux autres services sur Internet fonc­tion­nent via de tels services Web. SOAP est l’un des pro­to­coles qui per­met­tent la com­mu­ni­ca­tion.

Remarque

À l’origine, on utilisait uni­que­ment le nom SOAP comme acronyme de « Simple Object Access Protocol ». Cependant, comme cette dé­no­mi­na­tion ne convient pas réel­le­ment au protocole (puisqu’il n’a rien de simple et qu’il n’utilise pas d’objets), on utilise sim­ple­ment SOAP.

SOAP est utilisé depuis les années 1990 afin de permettre la com­mu­ni­ca­tion entre un client – par exemple la na­vi­ga­teur Internet – et les services d’un serveur. Pour que cela fonc­tionne, le client doit soumettre des requêtes à une API. La forme de ces requêtes est définie par le framework de SOAP. Il est toutefois possible d’intégrer des données spé­ci­fiques à l’ap­pli­ca­tion dans cet ensemble de règles, ce qui constitue l’un des gros avantages de SOAP. Les services Web peuvent ainsi mettre à dis­po­si­tion des ap­pli­ca­tions diverses. Comme ces dernières ne doivent pas né­ces­sai­re­ment avoir la même syntaxe pour être utilisées comme un service Web, SOAP définit seulement les règles de base.

Note

Le dé­ve­lop­peur de logiciel Dave Wiener a créé SOAP en col­la­bo­ra­tion avec une équipe de Microsoft afin de proposer un protocole fonc­tion­nel pour Internet. Dans ce cadre, ils ont accordé une grande im­por­tance au fait que SOAP soit com­pa­tible avec la norme W3C. SOAP est ainsi re­com­mandé par le W3C.

Services Web SOAP – Domaines d’ap­pli­ca­tion du protocole

SOAP in­ter­vient lorsqu’un système doit accéder à un autre système de façon ordonnée et limitée. Au lieu de donner au client à l’origine de la requête un accès complet au serveur, l’accès peut être limité aux fonctions né­ces­saires grâce à un protocole tel que SOAP. Avec son ar­chi­tec­ture, SOAP présente l’avantage sup­plé­men­taire de pouvoir faire coopérer des systèmes très dif­fé­rents : le protocole met à dis­po­si­tion un cadre per­met­tant d’intégrer l’ap­pli­ca­tion spé­ci­fique.

Les services Web les plus divers sont basés sur SOAP. Amazon et eBay par exemple, tra­vail­lent (en partie) avec ce protocole réseau.

Structure de SOAP : fonc­tion­ne­ment du protocole

SOAP est basé sur le XML. Également re­com­mandé par le W3C, le XML est un ensemble d’unités d’in­for­ma­tion né­ces­saires à la bonne struc­tu­ra­tion d’un document XML (c’est-à-dire reprenant une structure re­com­man­dée). SOAP la reprend dans sa structure de messages et cor­res­pond donc sur le principe à un document XML.

Dans la plupart des cas, SOAP est également intégré dans le HTTP. Le transfert est donc réalisé via ce célèbre protocole et est intégré dans sa structure. En pratique, un message HTTP doté d’une requête SOAP ressemble à ce qui suit :

POST /example HTTP/1.1
Host: example.org
Content-Type: text/xml; charset=utf-8
…
<?xml version="1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope"
SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
...
    <SOAP-ENV:Header>
        ...
    </SOAP-ENV:Header>
    <SOAP-ENV:Body>
        ...
    </SOAP-ENV:Body>
</SOAP_ENV:Envelope>

Dans cet exemple, la requête commence donc avec un en-tête HTTP suivi par une enveloppe SOAP. À l’instar d’une enveloppe postale, celle-ci contient le contenu du message à pro­pre­ment parler. Les éléments de base de SOAP sont alors l’en-tête et le corps.

  • En-tête : l’en-tête de la requête SOAP contient des mé­ta­don­nées, par exemple sur le cryptage utilisé. Son uti­li­sa­tion est fa­cul­ta­tive.
  • Corps : le corps du message contient les données à pro­pre­ment parler.

Les termes contenus dans le corps n’ont rien à voir avec SOAP et dépendent en­tiè­re­ment de l’ap­pli­ca­tion.

Le protocole est souvent utilisé en as­so­cia­tion avec le Web Services Des­crip­tion Language (WSDL). Il s’agit d’un langage de des­crip­tion spé­ci­fique aux services Web et mul­ti­pla­te­formes. À l’aide de ce langage, un client peut iden­ti­fier quels services sont offerts par un service Web. À partir du fichier WSDL, le client détermine les pos­si­bi­li­tés dont il dispose pour une requête SOAP. Utilisés ensemble, WSDL et SOAP per­met­tent donc à deux systèmes dif­fé­rents de com­mu­ni­quer sans mo­di­fi­ca­tions préa­lables.

SOAP vs. REST

SOAP et REST (le second est en fait une ar­chi­tec­ture et non un protocole) sont tous deux utilisés pour les services Web, mais abordent la tâche dif­fé­rem­ment. Alors que SOAP dispose d’un peu plus d’an­cien­neté, REST (ou RESTful Web­ser­vices) a aujourd’hui largement rattrapé son retard et met à dis­po­si­tion env. 70 pour cent des services Web sur Internet.

Le deux pré­sen­tent toutefois des avantages dif­fé­rents : REST est par exemple considéré comme re­la­ti­ve­ment simple, travaille avec d’autres formats que le XML et est plus rapide et plus léger comparé à SOAP. La liberté dont dispose REST par rapport au XML (on a souvent recours à JSON) est compensée par la liberté de choix du protocole dans le cas de SOAP. Même si le HTTP est le choix le plus fréquent, en théorie, SOAP fonc­tionne également avec FTP, SMTP ou d’autres pro­to­coles.

SOAP dispose par ailleurs d’un gros avantage en ce qui concerne la sécurité : WS-Security (spé­ci­fi­ca­tions sur les aspects en matière de sécurité pour les services Web) est so­li­de­ment ancré dans le protocole réseau. Les erreurs sont également mieux gérées dans SOAP, puisque celui-ci intègre di­rec­te­ment une fonc­tion­na­lité prévoyant la ré­pé­ti­tion des requêtes.

En résumé

SOAP et REST pré­sen­tent tous les deux des avantages et des in­con­vé­nients. On ne peut pas dire qu’une solution est meilleure que l’autre de façon générale. Pour des raisons de sim­pli­cité, la plupart des dé­ve­lop­peurs utilisent toutefois REST. En fin de compte, le choix dépendra du langage de pro­gram­ma­tion que l’on souhaite utiliser et du contexte dans lequel on souhaite utiliser le protocole.

Aller au menu principal