SOAP : explication du protocole réseau

Communiquer dans des réseaux comme Internet peut uniquement fonctionner si l’on se base sur des règles précises. Afin de garantir que les différents ordinateurs et d’autres appareils compatibles avec le réseau ne sombrent pas dans le chaos, ils doivent observer un protocole réseau. Avec REST, SOAP est l’un des principaux protocoles sur Internet.

Qu’est-ce que SOAP ?

La communication sur Internet est en principe basée sur des protocoles tels que HTTP, HTTPS, FTP ou – à un autre niveau – TCP. SOAP est toutefois uniquement utilisé pour les services Web. Il s’agit d’une interface permettant à un appareil d’utiliser le service d’un serveur. Les moteurs de recherche, les boutiques en ligne et de nombreux autres services sur Internet fonctionnent via de tels services Web. SOAP est l’un des protocoles qui permettent la communication.

Remarque

À l’origine, on utilisait uniquement le nom SOAP comme acronyme de « Simple Object Access Protocol ». Cependant, comme cette dénomination ne convient pas réellement au protocole (puisqu’il n’a rien de simple et qu’il n’utilise pas d’objets), on utilise simplement SOAP.

SOAP est utilisé depuis les années 1990 afin de permettre la communication entre un client – par exemple la navigateur Internet – et les services d’un serveur. Pour que cela fonctionne, 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écifiques à l’application dans cet ensemble de règles, ce qui constitue l’un des gros avantages de SOAP. Les services Web peuvent ainsi mettre à disposition des applications diverses. Comme ces dernières ne doivent pas nécessairement 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éveloppeur de logiciel Dave Wiener a créé SOAP en collaboration avec une équipe de Microsoft afin de proposer un protocole fonctionnel pour Internet. Dans ce cadre, ils ont accordé une grande importance au fait que SOAP soit compatible avec la norme W3C. SOAP est ainsi recommandé par le W3C.

Services Web SOAP – Domaines d’application du protocole

SOAP intervient 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écessaires grâce à un protocole tel que SOAP. Avec son architecture, SOAP présente l’avantage supplémentaire de pouvoir faire coopérer des systèmes très différents : le protocole met à disposition un cadre permettant d’intégrer l’application spécifique.

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

Structure de SOAP : fonctionnement du protocole

SOAP est basé sur le XML. Également recommandé par le W3C, le XML est un ensemble d’unités d’information nécessaires à la bonne structuration d’un document XML (c’est-à-dire reprenant une structure recommandée). SOAP la reprend dans sa structure de messages et correspond 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 à proprement 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étadonnées, par exemple sur le cryptage utilisé. Son utilisation est facultative.
  • Corps : le corps du message contient les données à proprement parler.

Les termes contenus dans le corps n’ont rien à voir avec SOAP et dépendent entièrement de l’application.

Le protocole est souvent utilisé en association avec le Web Services Description Language (WSDL). Il s’agit d’un langage de description spécifique aux services Web et multiplateformes. À l’aide de ce langage, un client peut identifier quels services sont offerts par un service Web. À partir du fichier WSDL, le client détermine les possibilités dont il dispose pour une requête SOAP. Utilisés ensemble, WSDL et SOAP permettent donc à deux systèmes différents de communiquer sans modifications préalables.

SOAP vs. REST

SOAP et REST (le second est en fait une architecture et non un protocole) sont tous deux utilisés pour les services Web, mais abordent la tâche différemment. Alors que SOAP dispose d’un peu plus d’ancienneté, REST (ou RESTful Webservices) a aujourd’hui largement rattrapé son retard et met à disposition env. 70 pour cent des services Web sur Internet.

Le deux présentent toutefois des avantages différents : REST est par exemple considéré comme relativement 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 fonctionne également avec FTP, SMTP ou d’autres protocoles.

SOAP dispose par ailleurs d’un gros avantage en ce qui concerne la sécurité : WS-Security (spécifications sur les aspects en matière de sécurité pour les services Web) est solidement ancré dans le protocole réseau. Les erreurs sont également mieux gérées dans SOAP, puisque celui-ci intègre directement une fonctionnalité prévoyant la répétition des requêtes.

En résumé

SOAP et REST présentent tous les deux des avantages et des inconvénients. On ne peut pas dire qu’une solution est meilleure que l’autre de façon générale. Pour des raisons de simplicité, la plupart des développeurs utilisent toutefois REST. En fin de compte, le choix dépendra du langage de programmation que l’on souhaite utiliser et du contexte dans lequel on souhaite utiliser le protocole.

Cet article vous a-t-il été utile ?