Comment tester les services web SOAP et WSDL dans Apidog

On vous a fourni un point de terminaison SOAP : un convertisseur de devises hérité, un service de commandes .NET d’un partenaire ou une intégration critique de facturation. Votre objectif est simple : appeler le service, valider son contrat XML et automatiser les contrôles à chaque évolution. Contrairement à REST, SOAP impose une enveloppe XML complète, un Content-Type précis et, souvent, un WSDL qui décrit les opérations disponibles.

Essayez Apidog dès aujourd’hui

Apidog prend en charge SOAP et WebService en plus de REST, GraphQL et gRPC. Vous pouvez soit envoyer une enveloppe SOAP manuellement, soit importer un WSDL pour générer les opérations et l’environnement. Pour comparer les protocoles, consultez REST, GraphQL, gRPC et SOAP. La spécification SOAP du W3C reste la référence pour la structure des messages.

Qu’est-ce que SOAP, et pourquoi sa gestion est différente

SOAP (Simple Object Access Protocol) est un protocole de communication XML conçu pour l’interopérabilité entre plateformes et langages. Un client Java peut ainsi communiquer avec un service .NET via un contrat commun, sans dépendre de l’implémentation interne.

Pour tester un service SOAP, retenez ces points :

• Les requêtes et réponses sont des documents XML structurés, pas des objets JSON.
• SOAP transite généralement via HTTP ou HTTPS.
• La structure est stricte : espaces de noms, enveloppe, corps et règles de validation doivent correspondre au contrat.

Si nécessaire, consultez la référence XML de MDN. Pour approfondir la structure des messages, lisez aussi ce guide sur les API SOAP et XML.

Cette rigueur explique l’usage continu de SOAP dans les intégrations multiplateformes, les systèmes historiques et les transactions utilisant WS-Security. Une requête REST classique ne suffit pas : vous devez fournir le bon en-tête HTTP et une enveloppe SOAP XML valide.

Avant de commencer

Pour envoyer des requêtes SOAP ou WebService dans Apidog, utilisez la version 2.1.31 ou ultérieure. Vérifiez votre version avant de continuer.

Préparez également :

• l’URL du point de terminaison ;
• le nom de l’opération à appeler ;
• les paramètres attendus ;
• le fichier WSDL, si le service en fournit un.

Méthode A : envoyer une requête SOAP manuellement

Utilisez cette méthode lorsque vous connaissez déjà l’URL du service, l’opération et les paramètres attendus.

Étape 1 : définir le Content-Type

Ajoutez manuellement l’un de ces en-têtes dans la section Headers de la requête :

Content-Type: text/xml; charset=utf-8

ou :

Content-Type: application/soap+xml

En pratique :

• SOAP 1.1 utilise généralement text/xml; charset=utf-8.
• SOAP 1.2 utilise souvent application/soap+xml.

Vérifiez le WSDL ou la documentation du fournisseur. En cas d’erreur liée au type de contenu, testez l’autre valeur.

Étape 2 : choisir le corps XML et coller l’enveloppe

Dans Apidog, définissez le format du corps sur xml, puis ajoutez l’enveloppe SOAP.

Exemple avec l’opération publique NumberToWords :

<?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>

Points à vérifier :

• soap:Envelope contient les espaces de noms requis.
• soap:Body contient l’appel métier.
• web:NumberToWords est le nom de l’opération.
• web:ubiNum est le paramètre transmis.

Ne devinez pas l’espace de noms : récupérez-le depuis le WSDL.

Étape 3 : envoyer et valider la réponse XML

Envoyez la requête. La réponse doit également être une enveloppe SOAP :

<?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>

Vérifiez au minimum :

1. la présence de l’enveloppe SOAP ;
2. la présence de l’opération de réponse, ici NumberToWordsResponse ;
3. la valeur dans NumberToWordsResult.

Le nom de l’opération de réponse reprend généralement le nom de l’opération avec le suffixe Response.

La documentation webservice.apidog.io propose d’autres exemples de configuration et d’enveloppes.

Adapter l’exemple à votre service

Le mécanisme reste identique pour tous les services :

• Pour ConvertCurrency, envoyez par exemple fromCurrency, toCurrency et amount.
• Pour GetOrderStatus, envoyez un orderId.
• Vérifiez ensuite le nœud XML qui contient le montant converti ou le statut de commande.

Le flux ne change pas :

1. définir le Content-Type ;
2. écrire l’enveloppe XML ;
3. envoyer ;
4. valider la réponse XML.

Méthode B : importer un WSDL pour générer les points de terminaison

Saisir une enveloppe manuellement convient pour un appel isolé. Pour un service qui expose plusieurs opérations, importez le WSDL.

Un WSDL décrit notamment :

• les opérations disponibles ;
• leurs entrées et sorties ;
• l’adresse du service.

Dans Apidog :

1. Ouvrez Paramètres puis Importation de données.
2. Sélectionnez WSDL.
3. Téléversez un fichier .wsdl ou .xml.
4. Vérifiez l’aperçu des points de terminaison détectés.
5. Ouvrez l’onglet Environnements.
6. Vérifiez l’adresse du service.
7. Cliquez sur Confirmer.
8. Sélectionnez l’environnement importé dans le coin supérieur droit.
9. Envoyez une requête vers l’une des opérations générées.

Vérifier l’adresse du service avant l’import

L’adresse présente dans le WSDL devient l’URL de base de l’environnement importé. Contrôlez-la avant de cliquer sur Confirmer.

C’est important si le WSDL référence :

• un serveur de staging ;
• un ancien hôte ;
• une URL qui n’a jamais été mise à jour.

Sinon, vos requêtes partiront vers le mauvais environnement.

Sélectionner l’environnement importé

Après l’import, sélectionnez l’environnement créé automatiquement. Il contient l’URL de base du service.

Sans cet environnement actif, les requêtes peuvent échouer faute d’adresse de base.

Une fois l’import terminé, chaque opération du WSDL apparaît comme un point de terminaison appelable. Vous pouvez alors vérifier les réponses XML comme avec la méthode manuelle.

Pour migrer un projet complet, consultez le guide d’importation de projets SOAP.

L’import WSDL documenté accepte les fichiers .wsdl et .xml. L’import depuis une URL ou par collage direct du contenu WSDL n’est pas documenté : téléchargez donc le fichier avant l’import.

Venir de SoapUI

Si vos tests résident déjà dans SoapUI, partez de votre WSDL existant :

1. exportez ou récupérez le WSDL ;
2. importez-le avec la méthode B ;
3. vérifiez les opérations générées ;
4. configurez et sélectionnez l’environnement.

Vous conservez les opérations du service dans un espace de travail qui peut aussi contenir des API REST, des scénarios de test, du mocking et de la documentation. Consultez la comparaison Apidog contre SoapUI pour les différences de workflow.

Ajouter des assertions aux réponses SOAP

Une requête réussie indique que le service répond. Un test automatisé vérifie qu’il respecte son contrat.

Après avoir reçu une réponse SOAP, ajoutez des assertions sur :

• la présence du nœud de réponse attendu ;
• la valeur de l’élément de résultat ;
• le format ou la plage de la valeur retournée.

Exemples :

• Pour un service de devise, vérifiez que le montant retourné est numérique et cohérent avec la plage attendue.
• Pour un service de commandes, vérifiez que le statut appartient aux valeurs autorisées.

Vous pouvez ensuite construire un scénario reproductible :

1. créer une commande ;
2. extraire son identifiant ;
3. appeler GetOrderStatus avec cet identifiant ;
4. vérifier le statut final.

Le guide sur l’écriture d’un scénario de test avec Apidog explique comment réutiliser des valeurs extraites dans les requêtes suivantes. Ce modèle est indépendant du protocole : un même scénario peut combiner SOAP et REST.

Gérer WS-Security

Les services SOAP sécurisés utilisent souvent WS-Security pour l’authentification et le chiffrement des messages.

Dans ce cas, ajoutez un bloc wsse dans l’en-tête de l’enveloppe SOAP, puis envoyez l’enveloppe complète comme corps XML. Le processus reste le même :

1. définir le Content-Type ;
2. inclure l’en-tête de sécurité ;
3. envoyer l’enveloppe XML complète ;
4. vérifier la réponse.

Automatiser avec l’CLI Apidog

Une fois vos scénarios enregistrés, l’CLI Apidog permet de les exécuter depuis la ligne de commande, notamment dans un pipeline CI/CD.

Installez l’outil avec Node.js v16 ou ultérieur :

npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>

Exécutez ensuite un scénario avec l’environnement issu de l’import WSDL :

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli

Options utilisées :

• -t : ID du scénario de test ;
• -e : ID de l’environnement ;
• -r : rapporteur, par exemple cli, html ou junit.

Vous pouvez combiner plusieurs rapporteurs en les séparant par des virgules.

La documentation confirme que le runner exécute les scénarios et suites de tests enregistrés. Elle ne précise toutefois pas si les scénarios reposant sur des étapes SOAP sont exécutés sans interface graphique. Utilisez donc le CLI pour les scénarios HTTP de votre projet et la synchronisation CI des points de terminaison importés via WSDL, sans supposer un comportement spécifique à SOAP.

Pour l’intégration dans un pipeline, consultez le guide CLI Apidog CI/CD.

FAQ

Quel Content-Type utiliser pour SOAP ?

Utilisez text/xml; charset=utf-8 ou application/soap+xml. SOAP 1.1 attend généralement le premier, SOAP 1.2 le second. Vérifiez le WSDL et testez l’autre valeur en cas d’erreur de type de contenu.

Faut-il un forfait payant pour tester SOAP dans Apidog ?

L’exigence documentée est d’utiliser Apidog en version 2.1.31 ou supérieure. Aucune restriction de niveau ou d’hébergement autonome n’est indiquée pour la prise en charge SOAP ou WSDL.

Puis-je importer un WSDL depuis une URL ?

L’import documenté prend en charge les fichiers .wsdl et .xml. L’import via URL ou collage du contenu WSDL n’est pas documenté. Téléchargez le fichier, importez-le, puis sélectionnez l’environnement créé.

Comment tester SOAP et REST dans le même projet ?

Ajoutez vos opérations SOAP et vos points de terminaison REST dans le même espace de travail. Un scénario peut ensuite enchaîner les appels entre protocoles. Pour GraphQL, consultez le guide de test des API GraphQL dans Apidog.

Pourquoi mes requêtes WSDL atteignent-elles le mauvais serveur ?

Deux causes sont fréquentes :

1. l’adresse du service était incorrecte dans l’onglet Environnements lors de l’import ;
2. l’environnement importé n’est pas sélectionné dans le coin supérieur droit.

Vérifiez l’adresse, puis activez le bon environnement avant d’envoyer les requêtes.

En résumé

Pour tester un service SOAP dans Apidog, choisissez l’une des deux approches :

• Manuelle : définissez le Content-Type, sélectionnez un corps xml, collez l’enveloppe SOAP et vérifiez la réponse.
• Via WSDL : importez le fichier, vérifiez l’environnement généré, sélectionnez-le et appelez les opérations créées.

Dans les deux cas, vous obtenez des vérifications reproductibles pour confirmer que le service respecte toujours son contrat XML. Téléchargez Apidog en version 2.1.31 ou supérieure, importez votre WSDL et intégrez vos services SOAP aux mêmes pratiques de test que le reste de vos API.