SoapUI Mock Service: Guide d'installation et Alternative Moderne

En bref

Les services de maquette (mock services) de SoapUI simulent localement des points de terminaison SOAP ou REST, mais ils nécessitent un processus Java en cours d'exécution, une configuration manuelle de la répartition (dispatch), et ne peuvent pas être partagés au sein d'une équipe sans une machine partagée. La Maquette Intelligente (Smart Mock) d'Apidog génère des réponses de maquette à partir de votre schéma d'API, fonctionne dans le cloud et se partage automatiquement avec votre équipe.

💡

Apidog est une plateforme de développement d'API tout-en-un et gratuite, dotée d'une Maquette Intelligente intégrée qui crée des points de terminaison de maquette instantanés à partir de vos définitions d'API sans nécessiter l'exécution d'un processus Java local. Essayez Apidog gratuitement, aucune carte de crédit requise.

bouton

Introduction

Les services de maquette (mock services) résolvent un problème courant dans le développement d'API : vous souhaitez tester la manière dont votre code client gère un service avant que ce service ne soit prêt, ou vous voulez tester des cas limites (erreurs, réponses lentes) sans les provoquer dans un système réel.

La fonctionnalité de service de maquette de SoapUI est disponible depuis les premières versions et elle fonctionne. Elle exécute un serveur HTTP local qui répond aux requêtes selon les règles que vous configurez. Le problème est que ce processus local crée des frictions : il s'arrête lorsque vous fermez SoapUI, les autres membres de l'équipe ne peuvent pas y accéder sans astuces de réseau, et l'interface de configuration est lourde.

Ce guide explique le fonctionnement des services de maquette de SoapUI, comment les configurer, les problèmes courants rencontrés par les équipes, et comment l'approche d'Apidog se compare.

Fonctionnement des services de maquette de SoapUI

SoapUI crée des services de maquette à partir des interfaces SOAP ou REST existantes dans votre projet. Le service de maquette :

Écoute sur un port local que vous configurez (par exemple, http://localhost:8088/MockService)
Intercepte les requêtes entrantes
Fait correspondre la requête à une « réponse de maquette » en utilisant la logique de répartition (dispatch)
Renvoie la réponse configurée

Pour les services SOAP, SoapUI peut générer automatiquement des réponses de maquette à partir de votre WSDL, créant des réponses de stub pour chaque opération. C'est utile pour simuler un service avant qu'il n'existe ou avant que vous n'ayez accès au véritable point de terminaison.

Configuration d'un service de maquette SoapUI (étape par étape)

Pour une interface SOAP

Dans votre projet SoapUI, faites un clic droit sur une interface SOAP dans l'arborescence du projet.
Sélectionnez « Générer un MockService » (Generate MockService).
Dans la boîte de dialogue, configurez :

Nom du service (par exemple, « Maquette OrderService »)
Numéro de port (par défaut 8088 ; modifiez-le si ce port est déjà utilisé)
Chemin (par exemple, /orders)

Cliquez sur OK. SoapUI crée un nœud MockService dans l'arborescence de votre projet.
Développez le nœud MockService. Vous verrez une « MockOperation » pour chaque opération SOAP de l'interface.
Double-cliquez sur une MockOperation pour ouvrir l'éditeur de réponse de maquette.
Modifiez le XML de la réponse SOAP pour renvoyer les valeurs que vous souhaitez simuler.
Cliquez sur le bouton de lecture vert dans l'éditeur MockService pour démarrer le serveur local.

Votre maquette est maintenant en cours d'exécution à l'adresse http://localhost:8088/orders. Dirigez votre code client vers cette URL.

Pour une interface REST

Faites un clic droit sur une interface ou une ressource REST dans l'arborescence du projet.
Sélectionnez « Ajouter au MockService » (Add to MockService) ou « Générer un MockService » (Generate MockService).
Configurez le port et le chemin comme ci-dessus.
Pour chaque ressource/méthode, configurez le corps de la réponse de maquette et le code de statut.
Démarrez le service de maquette.

Configuration de la répartition (dispatch)

Par défaut, le service de maquette de SoapUI renvoie la première réponse de maquette qu'il trouve. Si vous souhaitez des réponses différentes pour des entrées différentes, configurez un « script de répartition » (dispatch script) (Groovy) ou utilisez le type de répartition « SÉQUENCE » (SEQUENCE).

Répartition Séquence : Renvoie les réponses dans un ordre fixe lors des appels successifs. L'appel 1 reçoit la réponse A, l'appel 2 reçoit la réponse B.

Répartition SCRIPT : Un script Groovy inspecte la requête et renvoie un nom de réponse basé sur une logique.

Exemple de script de répartition :

def request = mockRequest.getRequestContent()
if (request.contains("orderId>12345")) {
  return "OrderFoundResponse"
} else {
  return "OrderNotFoundResponse"
}

Vous créez plusieurs réponses de maquette nommées (par exemple, « OrderFoundResponse », « OrderNotFoundResponse ») et le script de répartition sélectionne laquelle renvoyer en fonction du contenu de la requête entrante.

Problèmes courants des services de maquette SoapUI

Problème 1 : La maquette s'arrête lorsque SoapUI se ferme

Le service de maquette de SoapUI s'exécute dans le cadre du processus JVM de SoapUI. Lorsque vous fermez SoapUI, la maquette s'arrête. Les coéquipiers qui utilisent la maquette la perdent.

Solutions de contournement :

Gardez SoapUI ouvert sur une machine ou une VM dédiée
Utilisez l'option de serveur de maquette en ligne de commande de SoapUI : mockservicerunner.sh -p 8088 -s "OrderService Mock" project.xml
Utilisez une machine partagée persistante qui exécute toujours la maquette

Aucune de ces solutions n'est élégante. L'option en ligne de commande aide, mais elle nécessite toujours une machine avec SoapUI et Java installés.

Problème 2 : Partager la maquette au sein de l'équipe

Une maquette sur localhost:8088 n'est accessible qu'à la personne qui l'exécute. Pour que les coéquipiers puissent accéder à la même maquette, vous avez besoin d'un accès réseau à cette machine (règles de pare-feu, configuration VPN) ou d'exécuter la maquette sur un serveur partagé.

Problème 3 : Les scripts de répartition (dispatch) échouent avec du XML complexe

Les scripts de répartition de SoapUI utilisent la correspondance de chaînes Groovy sur le corps XML brut. Les enveloppes SOAP ont des espaces de noms, et la même valeur logique peut apparaître avec des préfixes d'espace de noms différents selon le client. Les scripts qui recherchent des chaînes littérales comme <orderId>12345</orderId> échouent lorsque le préfixe diffère.

La correction nécessite une analyse XML appropriée dans le script de répartition en utilisant la classe GroovyUtils de SoapUI, ce qui augmente la complexité.

Problème 4 : L'état ne persiste pas entre les appels

Les services de maquette de SoapUI sont par défaut sans état. Si vous souhaitez simuler un flux de travail de création-puis-lecture (POST pour créer, GET pour récupérer), vous avez besoin d'un script de répartition Groovy qui stocke l'état dans une variable partagée. Cela fonctionne mais est fragile.

Problème 5 : SSL pour les services de maquette

La configuration de HTTPS pour un service de maquette SoapUI nécessite la mise en place d'un magasin de clés (keystore), la configuration des paramètres SSL de SoapUI et l'orientation des clients vers le bon certificat. C'est considérablement plus complexe que les maquettes HTTP uniquement.

Maquette Intelligente Apidog : comparaison

L'approche de maquette d'Apidog part de la conception de l'API, et non d'un processus en cours d'exécution.

Lorsque vous définissez un point de terminaison d'API dans Apidog (méthode, chemin, schéma de requête, schéma de réponse), Apidog génère automatiquement un point de terminaison de maquette dans le cloud. Aucune configuration n'est requise.

L'URL de la maquette ressemble à : https://{votre-projet}.mock.apidog.io/orders/{id}

Cette URL est :

Toujours en cours d'exécution (aucun processus local à démarrer ou arrêter)
Accessible à chaque membre de l'équipe ayant accès au projet
Générant des réponses à partir du schéma que vous avez défini

Comment Apidog génère les réponses de maquette

Apidog lit votre schéma de réponse (schéma JSON ou définition de réponse OpenAPI) et génère des données factices réalistes. Un schéma qui indique que orderId est une chaîne de caractères au format UUID renvoie un UUID aléatoire. Un schéma qui indique que amount est un nombre entre 0 et 10000 renvoie un nombre dans cette plage.

Vous pouvez également configurer des règles de maquette personnalisées pour des champs spécifiques. Réglez orderId pour toujours renvoyer "test-123" lorsque vous avez besoin d'une valeur prévisible.

Points de terminaison SOAP dans la Maquette Apidog

La Maquette Intelligente d'Apidog est conçue pour les points de terminaison REST avec des réponses JSON. Pour les points de terminaison SOAP, la configuration de la maquette est manuelle : vous créez une requête dans Apidog, configurez une réponse personnalisée avec une enveloppe SOAP, et utilisez le serveur de maquette d'Apidog pour la renvoyer.

C'est moins automatisé que la génération de maquette basée sur WSDL de SoapUI, mais cela fonctionne pour les équipes qui ont besoin d'une maquette SOAP simple sans exécuter de processus Java local.

Maquette avec état

Apidog prend en charge les scripts de réponse personnalisés pour un comportement de maquette avec état. Vous pouvez inspecter le corps de la requête dans un script de maquette JavaScript et renvoyer différentes réponses en fonction du contenu de la requête, de manière similaire aux scripts de répartition de SoapUI, mais en JavaScript.

Comparaison côte à côte

Caractéristique	Maquette SoapUI	Maquette Intelligente Apidog
Nécessite Java	Oui	Non
Toujours actif	Uniquement avec l'exécuteur en ligne de commande	Oui (cloud)
Accessible par l'équipe	Mise en réseau manuelle	Oui, via URL partagée
Auto-génération WSDL	Oui	Non
Basé sur le schéma REST	Non	Oui
Réponses dynamiques	Répartition Groovy	Scripts de maquette JavaScript
Prise en charge HTTPS	Configuration manuelle du keystore	Intégré
Maquette avec état	Via variables Groovy	Via scripts JavaScript
Gratuit	Oui	Oui

Quand utiliser l'un ou l'autre

Utilisez les services de maquette SoapUI lorsque :

Vous avez besoin de simuler un service SOAP basé sur WSDL et souhaitez des stubs de réponse auto-générés
Votre équipe travaille hors ligne ou derrière des contrôles réseau stricts
Vous êtes déjà profondément intégré dans l'écosystème SoapUI et ne souhaitez pas changer d'outils

Utilisez la Maquette Intelligente Apidog lorsque :

Votre équipe simule des points de terminaison REST et a besoin d'un accès partagé sans configuration réseau
Vous souhaitez des serveurs de maquette qui restent en fonctionnement sans intervention manuelle
Vous démarrez un nouveau projet et définissez le contrat API avant l'implémentation
Vous souhaitez éviter d'installer et de maintenir un environnement Java pour les services de maquette

FAQ

Puis-je exécuter les services de maquette SoapUI en mode headless (sans interface graphique) ?Oui. SoapUI inclut mockservicerunner.sh (Linux/macOS) et mockservicerunner.bat (Windows). Exécutez-les avec le chemin du fichier de projet et le nom du service. Vous avez toujours besoin de Java installé, mais l'interface graphique n'a pas besoin d'être ouverte.

Apidog prend-il en charge les services de maquette SOAP ?Partiellement. Vous pouvez configurer des réponses personnalisées avec du XML SOAP dans le serveur de maquette d'Apidog. Vous n'obtenez pas l'auto-génération de réponses de stub basée sur WSDL. Pour les équipes ayant des interfaces SOAP bien comprises, la configuration manuelle est gérable.

Les services de maquette SoapUI peuvent-ils simuler des réponses lentes ?Oui. Dans la configuration de la réponse de maquette, définissez une valeur de « Délai » (Delay) en millisecondes. Apidog prend également en charge la configuration du délai de réponse pour simuler des conditions de réseau lentes.

Combien de requêtes de maquette Apidog peut-il gérer ?Le serveur de maquette cloud d'Apidog gère les charges de développement et de test typiques. Pour les tests de performance à grand volume, un outil de serveur de maquette dédié peut être plus approprié.

Que se passe-t-il si deux membres de l'équipe ont besoin de réponses de maquette différentes pour le même point de terminaison ?Dans SoapUI, chaque personne exécute sa propre maquette locale et peut la configurer indépendamment. Dans Apidog, vous pouvez créer plusieurs environnements ou utiliser des paramètres de requête pour sélectionner différents scénarios de réponse. La fonctionnalité « Mock expects » d'Apidog vous permet de faire correspondre des conditions de requête spécifiques à des réponses spécifiques.

La maquette d'Apidog nécessite-t-elle que l'API soit entièrement définie au préalable ?Un schéma de réponse aide Apidog à générer des données réalistes, mais vous pouvez créer des réponses de maquette manuelles sans schéma complet. Définissez le point de terminaison, définissez un corps de réponse personnalisé, et la maquette fonctionne.

Le service de maquette de SoapUI est fonctionnel mais lié à un processus Java local. Pour les équipes modernes qui ont besoin de maquettes persistantes et partagées, l'approche basée sur le cloud d'Apidog élimine la surcharge de coordination.

bouton