On vous a fourni un point de terminaison SOAP. Il s'agit peut-être d'un convertisseur de devises hérité dont votre équipe de facturation dépend encore, ou d'un service web de gestion des commandes qu'un partenaire exécute sur .NET. Vous devez l'appeler, confirmer qu'il renvoie ce que le contrat promet, et prouver qu'il reste correct à mesure que le code autour de lui évolue. Les outils REST ne conviennent pas tout à fait, car SOAP exige une enveloppe XML complète, un Content-Type spécifique et un WSDL qui décrit chaque opération.
Apidog gère les requêtes SOAP et WebService en parallèle de REST, GraphQL et gRPC, vous n'avez donc pas besoin d'une application distincte pour le service hérité unique de votre stack. Ce guide explore les deux méthodes documentées : envoyer une requête SOAP manuellement, et importer un WSDL pour qu'Apidog construise l'environnement et les points de terminaison pour vous. Si vous souhaitez d'abord une vue d'ensemble des protocoles, notre comparaison de REST, GraphQL, gRPC et SOAP explique la place de chacun. Pour la définition formelle de la structure de l'enveloppe, la spécification SOAP du W3C est la source faisant autorité.
Qu'est-ce que SOAP, et pourquoi il nécessite une gestion différente
Apidog décrit SOAP comme le Simple Object Access Protocol (Protocole d'Accès aux Objets Simples), un protocole de communication basé sur XML qui permet à diverses plateformes et langages de programmation de communiquer entre eux. Cette seule idée explique pourquoi tant d'entreprises l'utilisent encore. Un client Java et un service .NET peuvent communiquer via le même contrat sans se soucier des détails internes de l'autre.
Trois propriétés sont importantes lorsque vous le testez. SOAP utilise XML pour le formatage des messages, donc chaque requête et réponse est un document structuré, et non un simple objet JSON. Si le XML lui-même est un territoire inconnu, la référence XML de MDN est une excellente introduction à la syntaxe que vous lirez et écrirez. Il transite généralement par HTTP ou HTTPS, bien que le protocole en supporte d'autres. Et il respecte les standards du W3C pour une communication structurée et fiable, c'est pourquoi la forme des messages est stricte et les règles de validation sont fermes.
Cette rigueur est la raison pour laquelle les points de terminaison SOAP restent en service pour l'intégration multiplateforme, les passerelles entre systèmes anciens et modernes, et les transactions sécurisées utilisant WS-Security pour des messages chiffrés et authentifiés. C'est aussi pourquoi vous ne pouvez pas simplement envoyer une requête de style REST à l'un d'eux. Vous avez besoin de l'en-tête correct, d'un corps XML enveloppé dans une enveloppe SOAP, et d'un moyen de lire le XML qui vous est retourné. Si vous souhaitez un aperçu plus détaillé de la manière dont l'enveloppe et son corps transportent les données, consultez notre analyse des API SOAP et XML.
Avant de commencer
Une exigence stricte conditionne tout ce qui suit. Pour envoyer une requête SOAP ou WebService, Apidog doit être en version 2.1.31 ou supérieure. Les versions antérieures ne le prennent pas en charge. Ouvrez Apidog, vérifiez votre version et mettez à jour si vous êtes en retard. Tout le reste de ce guide suppose que vous utilisez la version 2.1.31 ou ultérieure.
Si vous n'avez pas encore Apidog, téléchargez Apidog et suivez le guide. Essayez-le gratuitement, aucune carte de crédit requise.
Vous voudrez également avoir à portée de main les détails de votre service cible : l'URL du point de terminaison, le nom de l'opération que vous souhaitez appeler et ses paramètres. Si vous avez un fichier WSDL, gardez-le à proximité, car la seconde moitié de ce guide l'importe directement.
Méthode A : envoyer une requête SOAP manuellement
C'est la méthode à suivre lorsque vous disposez d'un point de terminaison et que vous connaissez l'opération que vous souhaitez appeler. Il y a trois choses que vous devez définir et qu'une requête REST n'exige pas, et bien les configurer est l'essentiel du travail.
Étape 1 : définir manuellement l'en-tête Content-Type
Les requêtes SOAP n'infèrent pas leur propre en-tête. Vous définissez vous-même le Content-Type, et il existe deux valeurs valides :
text/xml; charset=utf-8application/soap+xml
La bonne valeur dépend du service. Les points de terminaison SOAP 1.1 s'attendent généralement à text/xml; charset=utf-8, tandis que les points de terminaison SOAP 1.2 préfèrent souvent application/soap+xml. Si vous n'êtes pas sûr, vérifiez le WSDL ou la documentation du service, et si la première valeur renvoie une erreur concernant le type de contenu, passez à l'autre. Ajoutez l'en-tête dans la section En-têtes de la requête avant d'envoyer.
Étape 2 : définir le format du corps en XML et coller l'enveloppe
Définissez le format du corps de la requête sur xml, puis collez l'enveloppe SOAP. L'enveloppe est un document avec des déclarations d'espaces de noms et un élément Body qui contient l'opération que vous appelez, ainsi que tous les paramètres imbriqués à l'intérieur.
Voici un exemple concret avec un service public de conversion de nombres en mots, la même structure qu'Apidog utilise dans sa documentation. L'opération est NumberToWords et prend un paramètre, ubiNum :
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:web="http://www.dataaccess.com/webservicesserver/">
<soap:Body>
<web:NumberToWords>
<web:ubiNum>1234</web:ubiNum>
</web:NumberToWords>
</soap:Body>
</soap:Envelope>
L'espace de noms de l'opération doit correspondre à ce que le service attend, c'est pourquoi vous le lisez depuis le WSDL plutôt que de deviner. Le soap:Body enveloppe l'appel réel ; web:NumberToWords est l'opération ; web:ubiNum est l'entrée.
Étape 3 : envoyer et lire la réponse XML
Envoyez la requête. La réponse est renvoyée en XML, sous forme d'une enveloppe SOAP dont le corps contient l'opération de réponse. Pour l'appel ci-dessus, vous obtenez un NumberToWordsResponse avec le résultat imbriqué à l'intérieur :
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<m:NumberToWordsResponse xmlns:m="http://www.dataaccess.com/webservicesserver/">
<m:NumberToWordsResult>one thousand two hundred and thirty four</m:NumberToWordsResult>
</m:NumberToWordsResponse>
</soap:Body>
</soap:Envelope>
La réponse reflète la requête : le nom de l'opération prend un suffixe Response, et la valeur atterrit dans un élément de résultat. C'est ce miroir que vous vérifiez. Vous confirmez que l'enveloppe est revenue, que le nœud NumberToWordsResponse existe et que le résultat correspond à ce que vous attendiez. La documentation dédiée aux services Web d'Apidog à l'adresse webservice.apidog.io contient la référence complète de configuration et d'autres exemples d'enveloppes si vous souhaitez un deuxième exemple détaillé.
Un cas d'utilisation réaliste suit les trois mêmes étapes. Remplacez NumberToWords par une opération ConvertCurrency sur un service de taux de change hérité, passez fromCurrency, toCurrency et amount comme éléments imbriqués, et lisez le chiffre converti à partir de l'enveloppe de réponse. Ou appelez une opération GetOrderStatus sur un service web de commande, passez un orderId, et vérifiez le nœud d'état renvoyé. La mécanique ne change jamais : en-tête, corps XML, envoi, lecture de l'enveloppe.
Méthode B : importer un WSDL pour générer les points de terminaison
Saisir des enveloppes à la main convient pour un seul appel. Lorsqu'un service expose une douzaine d'opérations, laissez le WSDL faire le travail. Un fichier WSDL décrit chaque opération, ses entrées et l'adresse du service, et Apidog lit tout cela en une seule importation.
Voici le chemin de clics exact :
- Allez dans Paramètres, puis Importation de données.
- Sélectionnez
WSDL. - Téléchargez votre fichier
.wsdlou.xml. - Vérifiez l'aperçu des points de terminaison API qu'Apidog a analysés à partir du fichier.
- Ouvrez l'onglet
Environnementset vérifiez que l'adresse du service est correcte. - Cliquez sur
Confirmer. L'environnement importé est créé automatiquement. - Sélectionnez l'environnement importé dans le coin supérieur droit.
- Envoyez une requête. L'URL de base est appliquée automatiquement à partir de cet environnement.
Deux étapes de cette liste sont celles que les gens sautent et regrettent ensuite.
L'étape 5 est importante car l'adresse du service dans le WSDL est le point de terminaison que chaque requête importée atteindra. Si elle pointe vers un hôte de staging, ou une URL de remplacement que l'auteur du WSDL n'a jamais mise à jour, vos requêtes iront au mauvais endroit. Vérifiez-le dans l'onglet Environnements avant de cliquer sur Confirmer, pas après.
L'étape 7 est importante car l'URL de base réside dans cet environnement créé automatiquement. Si vous ne sélectionnez pas l'environnement importé dans le coin supérieur droit, vos requêtes n'auront pas d'adresse de base et échoueront. Sélectionnez-le d'abord, puis envoyez.
Une fois importé, chaque opération apparaît comme un point de terminaison que vous pouvez appeler sans écrire l'enveloppe vous-même, et vous vérifiez la réponse XML exactement comme dans la Méthode A. Si vous déplacez un projet entier d'un autre outil, notre guide sur l'importation de projets SOAP couvre la migration de bout en bout.
Notez une limite honnête : l'importation WSDL est documentée pour le téléchargement de fichiers .wsdl et .xml. L'importation d'un WSDL par URL ou en collant le texte WSDL n'est pas documentée, alors téléchargez le fichier plutôt que de vous attendre à un champ d'URL.
Venir de SoapUI
Si vos tests SOAP résident actuellement dans SoapUI, vous n'avez pas à les reconstruire à partir d'une page blanche. Exportez ou conservez votre WSDL, importez-le dans Apidog avec la Méthode B, et vous obtiendrez les mêmes opérations en tant que points de terminaison appelables dans un espace de travail qui gère également la conception, le mocking et la documentation. Le gain est la consolidation : un seul projet contient votre service SOAP, vos points de terminaison REST et vos scénarios de test au lieu de les disperser sur des outils distincts. Notre comparaison Apidog contre SoapUI détaille ce qui est transféré et où les flux de travail diffèrent.
Assertions et variations
Un seul appel réussi prouve que le point de terminaison est actif. Un test prouve qu'il est correct. Une fois votre requête SOAP retournée, ajoutez des assertions sur l'enveloppe de réponse : confirmez que le nœud d'opération de réponse attendu est présent, extrayez l'élément de résultat et vérifiez sa valeur par rapport à ce que le contrat promet. Pour un service de devise, vous affirmez que le montant converti est un nombre dans la plage ; pour un service de commande, vous affirmez que le statut est l'une des valeurs autorisées.
À partir de là, vous construisez un scénario de test reproductible qui enchaîne les appels, par exemple créer une commande, puis interroger son statut, en passant des valeurs entre les étapes. Notre guide sur l'écriture d'un scénario de test avec Apidog montre comment connecter les valeurs extraites aux requêtes ultérieures. Le modèle est agnostique au protocole, de sorte qu'un scénario peut mélanger un appel SOAP avec les points de terminaison REST qui l'entourent.
Pour les points de terminaison sécurisés, SOAP utilise couramment WS-Security pour la messagerie chiffrée et authentifiée. Cet en-tête de sécurité fait partie de l'enveloppe SOAP que vous envoyez, vous ajoutez donc le bloc de sécurité wsse à l'intérieur de l'en-tête de l'enveloppe, en plus de votre opération. La mécanique d'envoi reste la même : définissez le Content-Type, placez l'enveloppe complète, y compris l'en-tête de sécurité, dans le corps XML, et envoyez.
Automatisez le flux de travail avec l'CLI Apidog
Une fois vos requêtes SOAP ou importées via WSDL enregistrées en tant que scénarios de test, l'CLI Apidog les exécute depuis la ligne de commande afin qu'un pipeline puisse les tester à chaque push. Installez-le avec Node.js v16 ou ultérieur, puis authentifiez-vous :
npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>
Exécutez un scénario enregistré par ID, par rapport à l'environnement créé par votre importation WSDL :
apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli
Ici, -t est l'ID du scénario de test, -e est l'ID de l'environnement, et -r est le rapporteur (cli, html, ou junit, séparés par des virgules pour plusieurs). Une mise en garde honnête : la documentation confirme que le runner exécute les scénarios et suites de tests enregistrés, mais elle ne précise pas si les scénarios basés sur des étapes SOAP s'exécutent sans interface graphique. Considérez donc le CLI comme votre moteur pour les scénarios HTTP du projet et pour maintenir la synchronisation des points de terminaison importés via WSDL dans l'intégration continue, plutôt que de supposer une exécution spécifique à SOAP. L'intégration dans un pipeline est couverte dans notre guide CLI Apidog CI/CD.
FAQ
Quel Content-Type dois-je utiliser pour une requête SOAP ? Soit text/xml; charset=utf-8, soit application/soap+xml. Le bon dépend du service : les points de terminaison SOAP 1.1 s'attendent généralement au premier, les points de terminaison SOAP 1.2 au second. Définissez-le manuellement dans les en-têtes de la requête, et si vous obtenez une erreur de type de contenu, passez à l'autre valeur.
Ai-je besoin d'un forfait payant pour tester SOAP dans Apidog ? La seule exigence documentée est qu'Apidog soit en version 2.1.31 ou supérieure. Aucune restriction de niveau ou d'hébergement autonome n'est mentionnée pour le support SOAP ou WSDL, alors mettez à jour vers une version actuelle et vous serez prêt.
Puis-je importer un WSDL depuis une URL ? L'importation WSDL documentée accepte le téléchargement de fichiers .wsdl et .xml. L'importation par URL ou en collant le texte WSDL n'est pas documentée, alors téléchargez le fichier. Après l'importation, l'environnement est créé automatiquement et vous le sélectionnez dans le coin supérieur droit avant d'envoyer.
Comment tester les API SOAP et REST dans le même projet ? Apidog les traite comme des types de requêtes au sein d'un seul espace de travail, de sorte qu'un seul projet peut contenir des opérations SOAP à côté de points de terminaison REST et même d'appels GraphQL. Si GraphQL est également à l'ordre du jour, notre guide sur le test des API GraphQL dans Apidog couvre cet aspect, et un scénario de test peut enchaîner des requêtes à travers tous ces éléments.
Mes requêtes importées via WSDL atteignent le mauvais serveur. Que s'est-il passé ? Deux causes habituelles. Soit l'adresse du service dans l'onglet Environnements était incorrecte au moment de l'importation et vous avez cliqué sur Confirmer sans la vérifier, soit vous n'avez pas sélectionné l'environnement importé dans le coin supérieur droit, de sorte qu'aucune URL de base n'a été appliquée. Réimportez et vérifiez l'adresse, puis assurez-vous que le bon environnement est actif avant d'envoyer.
En résumé
Tester SOAP ne signifie pas forcément utiliser un outil hérité séparé. Dans Apidog, vous pouvez soit envoyer l'enveloppe manuellement (définissez le Content-Type, définissez le corps en xml, collez l'enveloppe, lisez la réponse XML), soit importer un WSDL et laisser Apidog construire les points de terminaison et l'environnement pour vous. Les deux méthodes mènent au même résultat : une vérification reproductible que votre service web respecte toujours son contrat. Téléchargez Apidog en version 2.1.31 ou supérieure, importez votre WSDL et soumettez vos services hérités aux mêmes tests que le reste de votre surface API.