Qu'est-ce que SOAP ? Définition du protocole des services web

Lorsqu'une banque vérifie un virement auprès d'un autre établissement, qu'une agence de voyages interroge le système de réservation d'une compagnie aérienne ou qu'une administration échange des données avec un organisme partenaire, des programmes informatiques doivent dialoguer entre eux, souvent écrits dans des langages différents et installés sur des machines très éloignées. Pour que ces échanges se passent sans malentendu, il faut une langue commune et des règles de politesse partagées. SOAP est l'une de ces langues : un protocole d'échange de messages qui permet à des applications de s'envoyer des demandes et des réponses structurées, rédigées dans le format XML et le plus souvent transportées par le protocole du Web, HTTP. Apparu à la fin des années 1990 et normalisé par le W3C au début des années 2000, il a été l'une des briques essentielles des services web en entreprise. Il a depuis été largement concurrencé par des approches plus légères, comme les API dites REST, mais il reste très présent dans les systèmes bancaires, les assurances, les administrations ou les grands logiciels de gestion. Cet article explique ce qu'est SOAP, comment est construit un message, comment se déroule un échange, et quels sont ses atouts et ses limites.

Qu'est-ce que SOAP ? Définition du protocole

SOAP est une spécification qui définit la manière de construire et d'échanger des messages entre applications dans un réseau informatique. À l'origine, le sigle signifiait Simple Object Access Protocol, « protocole simple d'accès aux objets », mais cette signification a été abandonnée avec la version 1.2 de la norme : SOAP est désormais un nom propre, d'autant que le protocole n'est ni particulièrement simple ni limité à l'accès à des objets. Concrètement, un message SOAP est un document XML, c'est-à-dire un texte organisé par des balises, qui suit une structure précise : une enveloppe contenant un éventuel en-tête et un corps. Ce message est confié à un protocole de transport, généralement HTTP, le même que celui qu'utilisent les navigateurs, mais d'autres moyens sont possibles. SOAP ne dit rien du langage dans lequel sont écrits les programmes qui l'utilisent : une application Java peut ainsi dialoguer avec un service écrit en C# ou en PHP. Il est souvent comparé aux API REST, qui répondent au même besoin avec une philosophie plus légère, mais SOAP se distingue par son formalisme strict et ses nombreuses extensions normalisées.

Services web, API et protocoles : quelques repères

Pour bien situer SOAP, quelques notions méritent d'être précisées. Une API (interface de programmation) est un ensemble de fonctions qu'un logiciel met à la disposition d'autres logiciels, comme un guichet où l'on peut déposer des demandes selon des règles établies. Un service web est une API accessible à travers un réseau, le plus souvent Internet, par exemple un service qui calcule un tarif d'expédition, vérifie une adresse ou renvoie le cours d'une devise. Un protocole, enfin, est un ensemble de conventions qui fixe la forme des échanges, de la même manière que le protocole diplomatique règle le déroulement d'une visite officielle. SOAP est un protocole de messagerie destiné aux services web : il précise comment rédiger une demande, comment formuler une réponse et comment signaler une erreur. Il s'inscrit dans une approche dite orientée services, très en vogue dans les années 2000, qui consiste à découper le système d'information d'une organisation en services indépendants, dialoguant entre eux par messages. On parle souvent de « services web SOAP » pour désigner les services construits selon ce modèle, par opposition aux services REST, qui exploitent directement les mécanismes du protocole HTTP.

Quelle est l'histoire de SOAP ?

SOAP naît en 1998 chez Microsoft, de travaux menés notamment par Don Box, Bob Atkinson et Mohsen Al-Ghosein, avec le concours de Dave Winer, de la société UserLand. L'objectif était de permettre l'appel de procédures à distance, c'est-à-dire de demander à un programme situé sur une autre machine d'exécuter une fonction, en utilisant XML et HTTP, deux technologies ouvertes et largement disponibles, plutôt que des systèmes propriétaires complexes. Une version simplifiée de ces premiers travaux est publiée dès 1998 sous le nom de XML-RPC, qui connaîtra sa propre carrière. SOAP poursuit de son côté son développement avec le soutien d'IBM et d'autres industriels : la version 1.1 est soumise au W3C, le consortium qui élabore les standards du Web, en 2000. Le W3C crée un groupe de travail chargé de la normaliser, et la version 1.2 devient une recommandation officielle du W3C en 2003. Autour du protocole se développe alors toute une famille de normes complémentaires, regroupées sous l'appellation WS-* (pour Web Services), qui traitent de la sécurité, de la fiabilité de la livraison des messages, de l'adressage ou des transactions.

Comment fonctionne SOAP ? Une demande, une réponse

Le fonctionnement de SOAP se comprend bien à travers un exemple. Imaginons qu'une application de simulation immobilière veuille connaître le prix moyen des maisons dans une commune, information détenue par un service web distant. L'application, appelée client, rédige un message SOAP en XML qui précise l'opération demandée, par exemple « obtenir le prix moyen », ainsi que ses paramètres, ici le nom de la commune. Elle envoie ce message au serveur qui héberge le service, généralement par une requête HTTP de type POST adressée à une URL précise. Le serveur lit l'enveloppe, vérifie si l'en-tête contient des consignes particulières, par exemple des informations d'authentification, puis exécute l'opération en interrogeant sa base de données. Il construit à son tour une réponse SOAP, elle aussi en XML, contenant le résultat demandé, et la renvoie au client. Si un problème survient, comme un paramètre invalide ou une commune inconnue, la réponse contient un élément spécial, appelé Fault, qui décrit l'erreur de manière normalisée. Le client n'a plus qu'à extraire les données de la réponse pour les afficher ou les utiliser. Dans la pratique, les développeurs écrivent rarement ces messages à la main : des bibliothèques les génèrent et les analysent automatiquement.

Le WSDL, mode d'emploi du service

Pour qu'un client sache comment s'adresser à un service SOAP, il lui faut une description précise : quelles opérations sont proposées, quels paramètres elles attendent, sous quelle forme elles renvoient leurs résultats et à quelle adresse les joindre. Ce rôle est tenu par le WSDL (Web Services Description Language), un autre document XML qui constitue en quelque sorte le mode d'emploi officiel du service. Les types de données y sont définis à l'aide de schémas XML, qui précisent par exemple qu'un prix est un nombre décimal ou qu'une date doit respecter un format donné. Grand avantage de cette approche, les outils de développement savent lire un WSDL et générer automatiquement le code nécessaire pour appeler le service, dans le langage de programmation choisi : le développeur manipule alors des fonctions ordinaires, sans se soucier du XML échangé en coulisses. Ce formalisme agit comme un contrat entre le fournisseur du service et ses utilisateurs, ce qui est très apprécié dans les grandes organisations où des équipes différentes, parfois des entreprises différentes, doivent s'accorder sans ambiguïté. Il rend en revanche les évolutions plus lourdes, car toute modification du contrat doit être répercutée chez tous les clients.

Comment est construit un message SOAP ? Enveloppe, en-tête et corps

Un message SOAP ressemble à une lettre soigneusement emballée. L'enveloppe (Envelope) est l'élément racine du document XML : elle indique qu'il s'agit d'un message SOAP et précise la version utilisée, grâce à un identifiant appelé espace de noms. À l'intérieur, l'en-tête (Header), facultatif, peut contenir plusieurs blocs d'informations destinées au traitement du message plutôt qu'à son contenu : jeton d'authentification, signature numérique, identifiant de transaction, adresse de réponse, préférences de langue. Certains blocs peuvent être marqués comme obligatoires, ce qui oblige le destinataire à les comprendre sous peine de rejeter le message. Vient ensuite le corps (Body), obligatoire, qui renferme le contenu proprement dit : la demande, avec le nom de l'opération et ses paramètres, ou la réponse, avec les résultats. En cas d'erreur, le corps contient l'élément Fault, qui fournit un code, une explication lisible et éventuellement des détails techniques. Cette structure rigoureuse a un mérite : n'importe quel programme connaissant la norme sait où chercher chaque information, quel que soit le service.

Des messages indépendants du transport

L'une des particularités de SOAP est de ne pas être lié à un moyen de transport particulier. Dans l'immense majorité des cas, les messages voyagent par HTTP ou sa version sécurisée HTTPS, ce qui leur permet de franchir sans difficulté les pare-feu des entreprises, généralement configurés pour laisser passer le trafic web. Mais la norme prévoit d'autres liaisons possibles : un message SOAP peut être envoyé par courrier électronique, via le protocole SMTP, ou transiter par des systèmes de files d'attente de messages, utilisés en entreprise pour garantir qu'aucun message ne se perde même si le destinataire est temporairement indisponible. Cette neutralité permet de concevoir des échanges asynchrones, où la réponse arrive plus tard, et de faire passer un message par plusieurs intermédiaires, chacun pouvant traiter un bloc d'en-tête qui lui est destiné, par exemple pour vérifier une signature ou journaliser l'échange. Pour transmettre des fichiers volumineux, comme des images ou des documents PDF, des mécanismes complémentaires permettent d'attacher des pièces jointes binaires au message plutôt que de les encoder dans le texte XML, ce qui alourdirait considérablement les échanges.

Quels sont les avantages et les inconvénients de SOAP ?

Les atouts de SOAP expliquent sa longévité dans les grandes organisations. Sa normalisation poussée, du format des messages à la description des services, garantit l'interopérabilité entre des systèmes hétérogènes, issus de fournisseurs différents. Les normes complémentaires de la famille WS-* apportent des réponses standardisées à des besoins exigeants : WS-Security permet de signer et de chiffrer tout ou partie d'un message, indépendamment du canal de transport, d'autres normes garantissent la livraison fiable des messages ou la coordination de transactions entre plusieurs services. La gestion des erreurs est codifiée, les types de données sont strictement contrôlés par les schémas XML, et les outils génèrent automatiquement une grande partie du code. Ces qualités sont précieuses dans les secteurs où la traçabilité, la sécurité et la stabilité des échanges priment sur la légèreté : banque, assurance, santé, administration, télécommunications. Le tableau ci-dessous compare, de manière générale, SOAP et l'approche REST, qui s'est imposée pour la plupart des nouvelles API du Web, sachant que chaque projet peut nuancer ces caractéristiques.

Verbosité et complexité, les reproches faits à SOAP

Le principal reproche adressé à SOAP est sa verbosité. Le XML impose d'ouvrir et de fermer chaque balise, l'enveloppe et les espaces de noms ajoutent leur lot de texte, si bien qu'une simple question tenant en quelques mots peut produire un message de plusieurs centaines de caractères. Ces messages prennent plus de place sur le réseau et demandent davantage de calcul pour être analysés, ce qui pèse sur les applications mobiles ou les systèmes très sollicités. La complexité de l'écosystème est un autre frein : la multiplication des normes WS-*, leurs différentes versions et leurs interprétations parfois divergentes selon les éditeurs ont longtemps causé des problèmes de compatibilité entre implémentations censées respecter le même standard. Par ailleurs, en n'utilisant HTTP que comme un simple tuyau, SOAP se prive de mécanismes que le Web offre naturellement, comme la mise en cache des réponses ou la signification des différentes méthodes HTTP. Enfin, ses messages sont difficiles à lire et à tester à la main, là où une API REST se consulte parfois directement dans un navigateur. Ces limites expliquent pourquoi les développeurs du Web lui ont massivement préféré des solutions plus légères.

SOAP est-il encore utilisé aujourd'hui ?

Si SOAP n'est plus le choix par défaut pour concevoir une nouvelle API, il est loin d'avoir disparu. De très nombreux systèmes construits dans les années 2000 et 2010 continuent de reposer sur lui, et leur remplacement serait coûteux et risqué, surtout lorsqu'ils fonctionnent de manière fiable. On le rencontre ainsi dans les échanges interbancaires et les services de paiement, les systèmes de réservation du transport aérien et de l'hôtellerie, les plateformes de télédéclaration de certaines administrations, les logiciels de gestion intégrés des grandes entreprises, ou les systèmes d'information hospitaliers. Les développeurs qui intègrent ces services doivent donc toujours savoir manipuler un WSDL et une enveloppe SOAP. Dans le même temps, d'autres approches se sont développées pour répondre aux mêmes besoins d'échange de données structurées : REST et le format JSON pour la majorité des API web, GraphQL pour interroger finement des données, gRPC pour des échanges très rapides entre services internes, ou des protocoles fondés sur REST qui normalisent l'interrogation de bases de données à distance, à l'image d'OData, parfois présenté comme un successeur des services SOAP en entreprise.