SOAP n'a pas disparu. Les systèmes bancaires, les passerelles de paiement, les services gouvernementaux et les plates-formes d'entreprise plus anciennes exposent toujours des points de terminaison SOAP, et quelqu'un doit les tester. Si vous avez passé votre carrière sur REST et JSON, un service SOAP peut sembler étranger. Le protocole est plus strict, les charges utiles sont en XML et le contrat réside dans un fichier WSDL séparé.
La bonne nouvelle est que tester une API SOAP en ligne n'est pas difficile une fois que vous comprenez ce qu'elle attend réellement de vous. Ce guide explique en quoi les tests SOAP diffèrent des tests REST, présente une requête réelle et couvre les outils en ligne qui gèrent SOAP sans vous causer de difficultés.
Pourquoi les tests SOAP sont différents
REST est un style. SOAP est un protocole avec des règles. Cette distinction façonne tout ce qui concerne la façon dont vous le testez.
Un message SOAP est toujours un document XML encapsulé dans une enveloppe. L'enveloppe contient un en-tête pour les métadonnées comme l'authentification ou le routage, et un corps qui contient l'opération réelle et ses paramètres. Vous ne pouvez pas simplement envoyer un objet JSON non structuré. La structure est obligatoire, et une enveloppe mal formée est rejetée avant même que votre logique ne s'exécute. SOAP transite aussi presque toujours via HTTP POST, même pour les opérations qui ne font que lire des données, et il attend un Content-Type spécifique, généralement text/xml ou application/soap+xml.
La plus grande différence pratique est le WSDL. Un fichier WSDL, ou Web Services Description Language, est un contrat lisible par machine qui liste chaque opération offerte par le service, la forme exacte de chaque requête et réponse, et l'adresse du point de terminaison. REST propose rarement quelque chose d'aussi strict. Lorsque vous testez SOAP, le WSDL est votre carte. Un bon testeur SOAP en ligne lit le WSDL et génère des modèles de requête pour vous, afin que vous n'ayez pas à taper les enveloppes de mémoire. Si vous voulez une vue d'ensemble du contrat, nos notes sur les tests de contrat d'API expliquent pourquoi un contrat strict est un atout.
À quoi ressemble réellement une requête SOAP
Voici une requête SOAP réaliste vers un service de conversion de devises. Remarquez l'enveloppe, les déclarations d'espaces de noms et l'opération imbriquée dans le corps.
POST /CurrencyService.asmx HTTP/1.1
Host: rates.example.com
Content-Type: text/xml; charset=utf-8
SOAPAction: "https://rates.example.com/ConvertAmount"
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:cur="https://rates.example.com/">
<soap:Header>
<cur:AuthToken>e9f2a1c7-4b8d-4c2a-9f31-7d6e5a4b3c21</cur:AuthToken>
</soap:Header>
<soap:Body>
<cur:ConvertAmount>
<cur:FromCurrency>USD</cur:FromCurrency>
<cur:ToCurrency>EUR</cur:ToCurrency>
<cur:Amount>250.00</cur:Amount>
</cur:ConvertAmount>
</soap:Body>
</soap:Envelope>
La réponse revient encapsulée de la même manière :
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:cur="https://rates.example.com/">
<soap:Body>
<cur:ConvertAmountResponse>
<cur:ConvertAmountResult>231.45</cur:ConvertAmountResult>
</cur:ConvertAmountResponse>
</soap:Body>
</soap:Envelope>
Deux détails déroutent les gens. L'en-tête HTTP SOAPAction est requis par de nombreux services et doit correspondre à l'opération, sinon vous obtenez une erreur (fault). Et quand quelque chose échoue, SOAP ne renvoie pas une erreur HTTP 400 avec un message clair. Il renvoie un HTTP 200 avec un élément <soap:Fault> à l'intérieur du corps. Votre test doit analyser le corps pour savoir si l'appel a vraiment réussi. Vérifier le code de statut seul ne suffit pas, ce qui est l'une des raisons pour lesquelles les assertions d'API structurées sont plus importantes ici que dans REST.
Outils en ligne pour tester les API SOAP
Apidog
Apidog gère SOAP aux côtés de REST, GraphQL et WebSocket en un seul endroit. Vous importez un WSDL, et il génère la structure de la requête afin que vous n'ayez pas à construire les enveloppes manuellement. Vous pouvez ajouter des assertions sur les éléments XML, enchaîner des requêtes dans un scénario et exécuter l'ensemble comme une suite automatisée. Comme il conçoit et simule également des API, vous pouvez simuler une réponse SOAP avant que le service réel ne soit prêt. Téléchargez Apidog pour tester les services SOAP sur le plan gratuit.
SoapUI
SoapUI est l'outil de test SOAP original et toujours le plus complet. Pointez-le vers un WSDL et il construit un projet avec chaque opération. L'édition open source est gratuite et robuste pour les tests SOAP fonctionnels et axés sur les données. C'est une application de bureau Java plus lourde, et les fonctionnalités de rapport les plus raffinées se trouvent dans la version payante ReadyAPI. Pour en savoir plus, consultez ce qu'est SoapUI et comment il fonctionne.
Postman
Postman peut envoyer des requêtes SOAP. Vous définissez le corps en XML brut, ajoutez les en-têtes Content-Type et SOAPAction manuellement, et collez votre enveloppe. Cela fonctionne, mais Postman n'analyse pas un WSDL, vous devez donc construire les enveloppes vous-même. C'est bien pour une vérification ponctuelle et moins confortable pour une grande surface SOAP.
Testeurs SOAP basés sur navigateur
Plusieurs outils web légers vous permettent de coller une URL WSDL et d'envoyer des requêtes depuis un onglet de navigateur. Ils sont pratiques pour une vérification rapide sans rien installer. Les limites apparaissent rapidement : un support d'assertion limité, peu ou pas d'automatisation, et aucun moyen d'organiser une vraie suite de tests. Utilisez-les pour confirmer qu'un point de terminaison est actif, pas pour construire une suite de régression.
Un flux de travail rapide pour les tests SOAP
- Obtenez le WSDL. La plupart des services SOAP l'exposent en ajoutant
?wsdlà l'URL du point de terminaison. Ouvrez-le et confirmez qu'il se charge. - Importez le WSDL dans votre outil. Apidog et SoapUI génèrent des modèles de requête à partir de celui-ci. C'est le plus grand gain de temps.
- Remplissez les paramètres de l'opération. Utilisez des valeurs réelles. Testez une conversion de devise avec un montant réel et des codes de devise valides.
- Définissez les en-têtes. Confirmez le
Content-Typeet, si nécessaire, leSOAPAction. UnSOAPActionmanquant est la cause la plus fréquente d'une erreur inexpliquée. - Envoyez et inspectez le corps. Ne vous arrêtez pas au statut HTTP. Ouvrez le corps de la réponse et vérifiez la présence de
<soap:Fault>. - Ajoutez des assertions. Affirmez qu'un élément spécifique existe et contient la valeur attendue. Puis enchaînez un appel de suivi si votre flux en a besoin.
Pour organiser ceux-ci en un ensemble maintenable, notre guide sur la création de suites de tests pour l'automatisation d'API s'applique directement au travail SOAP.
Les erreurs SOAP et comment les affirmer
Une erreur SOAP (fault) est la structure d'erreur du protocole. Elle contient un faultcode, un faultstring et parfois un élément detail. Parce qu'elle arrive avec un HTTP 200, un test qui ne vérifie que le statut passera sur un appel échoué. C'est un faux positif silencieux et dangereux.
Écrivez vos assertions SOAP pour qu'elles examinent l'intérieur du corps. Affirmez qu'aucun élément <soap:Fault> n'est présent sur un chemin de succès. Sur un chemin d'erreur délibéré, affirmez le contraire, que l'erreur apparaît et que le faultcode correspond à ce que vous attendez. Tester les cas d'échec est aussi important que le chemin nominal, car les services SOAP encodent souvent les règles métier, comme une transaction refusée, sous forme d'erreurs plutôt que de données. La documentation des erreurs SOAP du W3C décrit la structure si vous avez besoin des détails formels.
WS-Security ajoute une autre couche. De nombreux services SOAP d'entreprise attendent un en-tête de sécurité signé ou contenant un jeton. Si vos requêtes échouent avec une erreur d'authentification, le WSDL ou la documentation du service indiquera quel profil de sécurité est en jeu. Des outils comme SoapUI et Apidog vous permettent de configurer ces en-têtes plutôt que de créer l'XML manuellement.
Lire un WSDL sans s'y perdre
Un fichier WSDL semble intimidant la première fois que vous l'ouvrez. C'est un XML long et profondément imbriqué, et la majeure partie est de la plomberie machine. Vous n'avez pas besoin de tout lire. Quatre parties contiennent les informations que vous voulez réellement.
La section types définit les structures de données, généralement sous forme de schéma XML, c'est donc là que vous apprenez la forme exacte et les contraintes de chaque paramètre. Les éléments message décrivent l'entrée et la sortie pour chaque opération. Le portType liste les opérations elles-mêmes, qui sont les appels que vous pouvez effectuer. Les sections service et binding donnent l'adresse concrète du point de terminaison et les détails du transport. Lorsque vous importez un WSDL dans un outil, il lit les quatre et les transforme en requêtes prêtes à être modifiées, c'est pourquoi l'importation est toujours préférable à la saisie manuelle.
Un détail à connaître : un WSDL peut être divisé en plusieurs fichiers utilisant des déclarations import, souvent en important des schémas depuis des emplacements séparés. Si votre outil signale un type manquant, un fichier référencé n'a probablement pas pu être résolu. Assurez-vous que chaque URL importée est accessible depuis l'endroit où votre outil s'exécute. Ce type de dépendance contractuelle est exactement la raison pour laquelle les équipes traitent le WSDL comme un artefact versionné plutôt que comme quelque chose qui ne vit que sur un serveur.
Tests SOAP axés sur les données
Les services SOAP comportent souvent des règles métier strictes, et une seule requête de chemin nominal prouve rarement grand-chose. Un service de devises doit être testé avec des paires valides, avec une devise non prise en charge, avec un montant nul et avec un montant négatif. Un service de paiement doit être testé avec une carte approuvée, une carte refusée et une carte expirée. Saisir chacun d'eux à la main est lent et facile à faire des erreurs.
Les tests axés sur les données résolvent ce problème. Vous écrivez la requête une fois avec des espaces réservés, puis vous lui fournissez un tableau de lignes d'entrée et de résultats attendus. L'outil exécute la requête pour chaque ligne et vérifie chaque résultat. SoapUI prend en charge ce modèle depuis des années, et Apidog le prend en charge via son exécuteur de scénarios. Le bénéfice est une couverture réelle des cas limites que les services SOAP ont tendance à encoder comme des erreurs. Pour le modèle plus large, notre guide sur les tests d'API axés sur les données avec CSV et JSON explique comment structurer les données d'entrée, et il s'applique à SOAP tout comme à REST.
Foire aux questions
Quelle est la différence entre les tests SOAP et REST ?
Les tests SOAP s'effectuent sur un protocole XML strict avec un contrat WSDL, des enveloppes obligatoires et des erreurs renvoyées à l'intérieur d'un corps HTTP 200. Les tests REST traitent généralement du JSON, des conventions plus souples et des codes de statut HTTP significatifs. Un test SOAP doit analyser le corps de la réponse pour confirmer le succès ; un test REST peut souvent se fier au code de statut.
Ai-je besoin du WSDL pour tester une API SOAP ?
Vous pouvez envoyer une requête SOAP sans le WSDL si vous connaissez déjà la structure exacte de l'enveloppe. Mais le WSDL facilite grandement les tests car les outils en génèrent des modèles de requête corrects. La plupart des services exposent le WSDL en ajoutant ?wsdl à l'URL du point de terminaison. Commencez toujours par là.
Pourquoi ma requête SOAP renvoie-t-elle une erreur (fault) même si le statut est 200 ?
SOAP signale les erreurs comme un élément <soap:Fault> à l'intérieur du corps, et non comme un code d'erreur HTTP, donc un 200 avec une erreur est normal. Les causes habituelles sont un en-tête SOAPAction manquant ou incorrect, une enveloppe mal formée, une non-concordance d'espace de noms ou un échec de vérification de sécurité. Lisez le faultstring pour la raison spécifique.
Puis-je tester les API SOAP en ligne gratuitement ?
Oui. Apidog prend en charge SOAP sur son plan gratuit et importe les fichiers WSDL, et l'édition open source de SoapUI est conçue pour SOAP. Des testeurs de navigateur légers existent également pour des vérifications rapides, bien qu'ils manquent de support d'assertion réel et d'automatisation.
Comment automatiser les tests d'API SOAP ?
Importez le WSDL, construisez un scénario qui enchaîne les opérations dans l'ordre, ajoutez des assertions sur les éléments de réponse et sur l'absence d'erreurs, puis exécutez-le depuis l'exécuteur d'un outil ou dans votre pipeline CI. SoapUI et Apidog prennent tous deux en charge les suites SOAP planifiées et déclenchées par pipeline, de sorte qu'une exécution de régression SOAP s'intègre dans le même flux d'automatisation que REST.