DEV Community

Cover image for Outils CLI gratuits et open source pour le mocking d'API
Antoine Laurent
Antoine Laurent

Posted on • Originally published at apidog.com

Outils CLI gratuits et open source pour le mocking d'API

Lorsque vous simulez une API depuis la ligne de commande, la licence compte autant que les fonctionnalités. Un serveur dont vous pouvez lire le code, auto-héberger et lancer en CI sans limite de postes n’a rien à voir avec une simulation SaaS dépendante d’un compte et d’une connexion. Ce guide se concentre sur des outils open source que vous pouvez cloner, inspecter et exécuter gratuitement.

Essayez Apidog dès aujourd’hui

Tous les outils listés sont publiés sous licence permissive (MIT ou Apache-2.0), disposent d’un dépôt GitHub public et peuvent être auto-hébergés sans compte. Si votre priorité est un exécutable minimal, un démarrage très rapide ou une faible empreinte d’installation, consultez plutôt les serveurs de simulation légers. Ici, le critère principal est l’ouverture du code et l’auto-hébergement.

Pour chaque outil, vous trouverez une commande de démarrage, un cas d’usage concret, ainsi que ses limites. Pour comparer aussi des solutions commerciales, consultez les meilleurs outils de simulation d’API et cette présentation des outils de simulation d’API REST.

Note sur Apidog : Apidog n’est pas open source. Il est mentionné à la fin comme alternative intégrée, mais les six outils numérotés ci-dessous sont réellement open source.

Qu’est-ce qui rend un outil de simulation CLI open source ?

Pour retenir un outil dans cette liste, vérifiez trois points.

  1. Licence permissive

    Le code doit être public et publié sous MIT ou Apache-2.0. Vous pouvez donc l’inspecter, le forker et l’intégrer à vos workflows sans frais de licence ni comptage de postes.

  2. Auto-hébergement réel

    L’outil doit pouvoir s’exécuter sur un poste local, dans Docker ou sur votre infrastructure. C’est essentiel pour les pipelines CI isolés ou les environnements air-gapped.

  3. Maintenance publique

    Le projet doit avoir un dépôt public, des versions, des issues et un historique de commits exploitable. Les étoiles GitHub sont un signal secondaire : privilégiez les versions taguées et l’activité récente.

La vitesse de démarrage et la taille d’installation ne sont pas les critères principaux ici. Une plateforme plus lourde reste pertinente si elle est open source et auto-hébergeable.

Prism (Stoplight)

Prism transforme une spécification OpenAPI ou Postman en serveur de simulation. Il sert les exemples définis dans le contrat, valide les requêtes entrantes et peut aussi fonctionner comme proxy de validation devant une API réelle.

Démarrer une simulation OpenAPI 

npm install -g @stoplight/prism-cli

prism mock https://raw.githubusercontent.com/stoplightio/prism/master/examples/petstore.oas2.yaml
Enter fullscreen mode Exit fullscreen mode

Prism démarre alors sur http://127.0.0.1:4010.

Testez immédiatement le serveur :

curl http://127.0.0.1:4010/pets
Enter fullscreen mode Exit fullscreen mode

La réponse est générée à partir des exemples présents dans votre document OpenAPI. Si vous envoyez une requête incompatible avec le schéma, Prism indique précisément la règle violée.

Quand l’utiliser

  • Votre fichier OpenAPI est la source de vérité.
  • Vous voulez détecter les écarts entre contrat et implémentation.
  • Vous avez besoin d’un proxy de validation dans vos tests d’intégration.

Limites

  • Les réponses ne sont riches que si vos exemples et schémas le sont.
  • Il n’y a pas de comportement métier avec état, comme « créer une ressource puis la relire ».
  • Node.js est nécessaire.

Mockoon CLI

Mockoon est connu pour son interface de bureau, mais sa CLI utilise le même moteur sans interface graphique. Vous pouvez démarrer un environnement Mockoon existant ou fournir un fichier OpenAPI.

Démarrer un environnement Mockoon 

npm install -g @mockoon/cli

mockoon-cli start --data ./environment.json --port 3000
Enter fullscreen mode Exit fullscreen mode

Vous pouvez aussi démarrer depuis une spécification OpenAPI :

mockoon-cli start --data ./openapi.yaml --port 3000
Enter fullscreen mode Exit fullscreen mode

Pendant l’écriture de vos règles, activez le rechargement et les logs détaillés :

mockoon-cli start \
  --data ./environment.json \
  --port 3000 \
  --watch \
  --log-transaction
Enter fullscreen mode Exit fullscreen mode

Quand l’utiliser

  • Vous avez besoin de réponses conditionnelles sans écrire de serveur.
  • Vous souhaitez utiliser du templating dans les réponses.
  • Vous voulez concevoir visuellement un environnement, puis l’exécuter en CI via CLI.
  • Vous devez proxifier certains appels vers une API réelle.

Limites

  • La création d’environnements est plus confortable dans l’application de bureau.
  • Modifier directement le JSON d’environnement peut devenir fastidieux.
  • Le templating dynamique demande un temps d’apprentissage.

json-server

json-server est une solution rapide pour exposer une API REST CRUD à partir d’un fichier JSON. Il persiste les modifications directement dans ce fichier.

Créer une API REST en une commande

Créez un fichier db.json :

{
  "posts": [
    {
      "id": 1,
      "title": "Premier article",
      "published": true
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

Démarrez le serveur :

npx json-server db.json
Enter fullscreen mode Exit fullscreen mode

Vous obtenez immédiatement des routes CRUD :

curl http://localhost:3000/posts
curl http://localhost:3000/posts/1

curl -X POST http://localhost:3000/posts \
  -H 'Content-Type: application/json' \
  -d '{"title":"Nouvel article","published":false}'
Enter fullscreen mode Exit fullscreen mode

Les routes GET, POST, PUT, PATCH et DELETE sont générées automatiquement. Vous pouvez aussi utiliser le filtrage, le tri et la pagination par paramètres de requête.

Quand l’utiliser

  • Votre frontend doit avancer avant que le backend soit disponible.
  • Vous avez besoin d’une simulation REST avec état.
  • Vous voulez une configuration minimale, sans installation globale.

Limites

  • Le modèle est volontairement orienté REST CRUD.
  • Il ne génère pas une simulation à partir d’OpenAPI.
  • Le fichier JSON devient le contrat de fait.
  • Ce n’est pas un outil destiné aux tests de charge ni à la reproduction complète d’un environnement de production.

WireMock

WireMock est un outil complet pour simuler des services HTTP. Il prend en charge la correspondance avancée des requêtes, les réponses dynamiques, les scénarios avec état, l’injection de fautes et l’enregistrement-relecture.

Démarrer WireMock avec Docker 

docker run -it --rm -p 8080:8080 wiremock/wiremock:latest
Enter fullscreen mode Exit fullscreen mode

Ajoutez ensuite un stub via l’API d’administration :

curl -X POST http://localhost:8080/__admin/mappings \
  -H 'Content-Type: application/json' \
  -d '{
    "request": {
      "method": "GET",
      "url": "/hello"
    },
    "response": {
      "status": 200,
      "body": "world"
    }
  }'
Enter fullscreen mode Exit fullscreen mode

Vérifiez le résultat :

curl http://localhost:8080/hello
# world
Enter fullscreen mode Exit fullscreen mode

Pour versionner vos simulations, placez vos fichiers JSON dans un répertoire mappings/ et montez-le dans le conteneur.

Quand l’utiliser

  • Vous testez des scénarios complexes et avec état.
  • Vous devez simuler des délais, erreurs réseau ou réponses dégradées.
  • Vous voulez enregistrer une API réelle puis rejouer son comportement.
  • Votre suite de tests a besoin d’une simulation proche du comportement d’un tiers réel.

Limites

  • WireMock repose sur la JVM : utilisez Docker ou installez Java.
  • Sa surface de configuration est importante pour un besoin très simple.
  • Contrairement à Prism, il ne propose pas une unique commande pour lire une spécification OpenAPI et démarrer.

MockServer

MockServer combine un serveur de simulation HTTP(S) et un proxy sur un seul port. Il est orienté tests d’intégration et permet de vérifier les appels reçus, de proxifier du trafic et d’injecter des erreurs.

Créer une attente HTTP

Démarrez MockServer :

docker run -d --rm -p 1080:1080 mockserver/mockserver
Enter fullscreen mode Exit fullscreen mode

Ajoutez une attente :

curl -X PUT 'http://localhost:1080/mockserver/expectation' \
  -H 'Content-Type: application/json' \
  -d '{
    "httpRequest": {
      "path": "/order"
    },
    "httpResponse": {
      "body": "{\"status\":\"ok\"}"
    }
  }'
Enter fullscreen mode Exit fullscreen mode

Appelez ensuite la route simulée :

curl http://localhost:1080/order
# {"status":"ok"}
Enter fullscreen mode Exit fullscreen mode

Vous pouvez définir les mêmes attentes depuis les clients MockServer pour Java, JavaScript, Ruby et d’autres langages, au lieu d’appeler l’API avec curl.

Quand l’utiliser

  • Vous devez combiner simulation, proxy et vérification des requêtes.
  • Vos tests doivent confirmer qu’un endpoint a été appelé un certain nombre de fois.
  • Vous avez besoin d’injecter des erreurs côté dépendance.
  • Votre stack de test est déjà fortement basée sur la JVM.

Pour comparer cet outil avec d’autres options, consultez les alternatives à MockServer.

Limites

  • Comme WireMock, MockServer nécessite un environnement JVM ou Docker.
  • Le format JSON des attentes est verbeux.
  • Son périmètre chevauche largement WireMock : choisissez selon la bibliothèque cliente et les conventions de votre stack.

Microcks

Microcks est une plateforme de simulation et de tests de contrat. Projet incubateur de la Cloud Native Computing Foundation, il prend en charge OpenAPI, AsyncAPI, gRPC, GraphQL, Postman et SoapUI.

Démarrer l’instance tout-en-un 

docker run -d --name microcks -p 8585:8080 quay.io/microcks/microcks-uber:latest
Enter fullscreen mode Exit fullscreen mode

Ouvrez ensuite http://localhost:8585, puis importez une spécification pour exposer des endpoints de simulation.

Le client microcks-cli permet d’automatiser les imports depuis la CI :

microcks-cli import 'petstore.yaml:true' \
  --microcksURL=http://localhost:8585/api \
  --keycloakClientId=... \
  --keycloakClientSecret=...
Enter fullscreen mode Exit fullscreen mode

Quand l’utiliser

  • Votre équipe gère un catalogue partagé de nombreuses API.
  • Vous avez besoin de simulations et de tests de conformité de contrat.
  • Vos interfaces dépassent HTTP REST : événements, Kafka, MQTT, gRPC ou GraphQL.
  • Vous recherchez une plateforme gouvernée plutôt qu’un simple processus local.

Limites

  • Microcks est une plateforme, pas un binaire autonome.
  • microcks-cli pilote une instance Microcks existante : il ne sert pas directement les simulations.
  • Pour une simulation locale unique, Prism ou json-server sont plus légers.

Un aparté honnête : Apidog

Apidog n’est pas open source et ne fait donc pas partie des outils open source ci-dessus. En revanche, si vous préférez éviter d’assembler plusieurs outils pour la conception, la simulation, les tests et la documentation, il peut être une alternative intégrée.

Apidog est une plateforme freemium dont le niveau gratuit inclut la simulation. La commande apidog mock de l’apidog-cli permet de gérer des attentes de simulation depuis le terminal. La simulation intelligente peut générer des valeurs de champ réalistes depuis votre schéma afin de réduire l’écriture manuelle d’exemples.

Le compromis est simple :

  • choisissez un des six outils open source si l’auto-hébergement isolé et l’ouverture du code sont obligatoires ;
  • choisissez Apidog si un workflow intégré, de la conception à la simulation, est prioritaire.

Comment choisir

Outil Idéal pour Installation Licence Notes
Prism Simulations pilotées par spécification et proxy de validation npm i -g @stoplight/prism-cli Apache-2.0 Entrée OpenAPI/Postman ; simulation sans état
Mockoon CLI Réponses basées sur des règles sans code npm i -g @mockoon/cli MIT Concevoir dans l’application, exécuter sans interface
json-server Faux backend REST avec état pour le frontend npx json-server db.json MIT CRUD persistant, zéro configuration
WireMock Scénarios de tests complexes et injection de fautes docker run wiremock/wiremock Apache-2.0 JVM ; enregistrement-relecture ; scénarios avec état
MockServer Simulation, proxy et vérification docker run mockserver/mockserver Apache-2.0 JVM ; HTTP/2, gRPC et WebSocket
Microcks Catalogue gouverné multi-API et multi-protocole docker run microcks-uber Apache-2.0 Plateforme CNCF ; la CLI est un client
Apidog (non OSS) Flux intégré de conception à simulation npm i -g apidog-cli Freemium Niveau gratuit ; apidog mock dans un projet unique

Choisissez selon la forme de votre besoin, pas selon la popularité :

  • Spécification OpenAPI comme source de vérité : commencez par Prism.
  • CRUD persistant pour débloquer un frontend : utilisez json-server.
  • Tests riches avec erreurs, délais et enregistrement-relecture : choisissez WireMock ou MockServer.
  • Catalogue partagé avec plusieurs protocoles et tests de contrat : déployez Microcks.
  • Réponses conditionnelles configurables sans écrire de code : utilisez Mockoon CLI.

Pour relier plus précisément les scénarios aux outils, consultez ce guide des cas d’utilisation de la simulation d’API.

En résumé

Les outils de simulation CLI open source vous donnent un serveur que vous pouvez lire, auto-héberger et lancer gratuitement en CI.

  • Prism et json-server couvrent les cas courants avec très peu de configuration.
  • WireMock et MockServer conviennent aux scénarios de test avancés.
  • Mockoon CLI facilite les réponses dynamiques et conditionnelles.
  • Microcks étend la simulation à un catalogue gouverné et à plusieurs protocoles.

Tous les six sont sous licence MIT ou Apache-2.0, auto-hébergeables et disponibles sur GitHub public.

Si vous préférez gérer simulations, conception d’API, tests et documentation dans un même environnement, téléchargez Apidog et essayez apidog mock avec le niveau gratuit. Ce n’est pas open source, mais cela centralise le flux de travail de la ligne de commande à la CI.

Top comments (0)