Vous avez besoin d'une fausse API pour le développement, et vous en avez besoin dans les trente secondes : pas de service hébergé, pas de pile Docker Compose, pas d'interface graphique à parcourir. Juste une commande qui lit un fichier et sert des réponses sur localhost.
Essayez Apidog dès aujourd'hui
Un serveur de maquette (mock server) léger répond à ce besoin. Pointez-le vers une spécification OpenAPI ou un fichier de données, lancez une commande, puis interrogez des endpoints réalistes depuis votre frontend ou vos tests pendant que le backend réel est encore en construction.
Ce guide compare six outils CLI, du plus rapide à démarrer aux options JVM plus complètes. Chaque commande ci-dessous est issue de la documentation officielle des outils. Pour une comparaison incluant les solutions GUI et hébergées, consultez les meilleurs outils de maquette d'API.
Qu'est-ce qui rend un outil de maquette CLI « léger » ?
La légèreté concerne surtout l'empreinte et le temps nécessaire pour obtenir une première réponse.
Évaluez quatre critères :
-
Installation et runtime : un package Node exécutable avec
npxest plus léger qu'un serveur JVM nécessitant Java. - Temps de démarrage : l'outil doit être disponible avant même que vous retourniez à votre éditeur.
- Configuration initiale : idéalement, un fichier et une commande suffisent.
- Usage terminal et CI : pas de compte, de dashboard ou d'étape GUI obligatoire.
Les trois options les plus directes sont Prism, Mockoon CLI et json-server : vous pouvez les lancer avec npx, sans installation globale.
Prism (Stoplight)
Prism transforme une spécification OpenAPI en serveur de maquette. C'est l'option la plus simple si votre contrat API existe déjà.
npx @stoplight/prism-cli mock ./openapi.yaml
La commande démarre un serveur sur http://127.0.0.1:4010.
Prism lit les paths, les examples et les schémas de votre spécification :
- il renvoie l'exemple défini pour une réponse ;
- il génère une réponse valide à partir du schéma si aucun exemple n'est défini ;
- il valide les requêtes entrantes selon le contrat ;
- une requête invalide reçoit un
422plutôt qu'une réponse silencieuse.
Pour l'installer globalement :
npm install -g @stoplight/prism-cli
Vous pourrez alors supprimer npx :
prism mock ./openapi.yaml
Idéal pour : les équipes qui travaillent à partir d'une spécification et veulent une maquette fidèle au contrat. Prism est sous licence Apache-2.0 et prend en charge OpenAPI 3.1, 3.0, 2.0 et les collections Postman.
Limite à connaître : Prism est sans état. Un POST ne persiste pas automatiquement une ressource pour un appel GET suivant. La qualité des réponses dépend également de la qualité de votre spécification et de vos exemples. Pour une approche contractuelle, il s'intègre bien avec les outils de maquette d'API REST.
Mockoon CLI
Mockoon CLI exécute un environnement de maquette depuis un fichier de données. Ce fichier peut provenir de l'application de bureau Mockoon ou d'une spécification OpenAPI JSON/YAML.
npx @mockoon/cli start --data ./mockoon-env.json --port 3000
Utilisez --data pour fournir :
- un fichier d'environnement Mockoon ;
- une spécification OpenAPI JSON ;
- une spécification OpenAPI YAML.
L'outil sert immédiatement l'API sur le port choisi. Si votre fichier provient d'une ancienne version de Mockoon, la CLI le migre en mémoire sans modifier le fichier source.
Pour une installation globale :
npm install -g @mockoon/cli
Idéal pour : les équipes qui conçoivent leurs routes dans une interface graphique, mais veulent exécuter les maquettes sans interface dans un pipeline CI ou sur un serveur. Mockoon CLI est sous licence MIT et propose une image Docker officielle.
Limite à connaître : les configurations de routes les plus riches sont généralement créées dans l'application de bureau. Modifier manuellement le JSON d'environnement peut être moins agréable que maintenir un simple fichier OpenAPI ou JSON.
json-server
json-server est une solution rapide lorsque vous n'avez pas encore de spécification OpenAPI. Vous définissez vos données dans un fichier JSON et l'outil génère une API REST avec CRUD.
Créez un fichier db.json :
echo '{ "posts": [{ "id": 1, "title": "hello" }] }' > db.json
Démarrez le serveur :
npx json-server db.json
Votre ressource est alors disponible sur :
http://localhost:3000/posts
Vous obtenez des endpoints REST pour :
GET /posts
GET /posts/:id
POST /posts
PUT /posts/:id
PATCH /posts/:id
DELETE /posts/:id
Contrairement à Prism, json-server maintient un état : un POST /posts ajoute réellement une ressource et réécrit db.json.
Exemple :
curl -X POST http://localhost:3000/posts \
-H "Content-Type: application/json" \
-d '{ "title": "Nouvel article" }'
Vous pouvez aussi utiliser des paramètres de requête pour filtrer, trier et paginer les données.
Pour l'installer globalement :
npm install -g json-server
Idéal pour : les développeurs frontend qui ont besoin d'un backend REST fonctionnel avant que la véritable API n'existe. Il est sous licence MIT et fait partie des serveurs de maquette légers pour API RESTful ne nécessitant pas de spécification.
Limite à connaître : json-server suit un modèle REST centré sur les ressources. Il n'est pas adapté aux routes très personnalisées, aux endpoints non REST ou à une validation stricte des en-têtes et du corps des requêtes.
MockServer
MockServer convient aux tests nécessitant une correspondance précise des requêtes. Vous pouvez faire correspondre une requête selon sa méthode, son chemin, ses en-têtes, ses paramètres ou son corps, puis définir exactement la réponse à retourner.
Démarrez le serveur :
java -jar mockserver-netty-5.15.0-no-dependencies.jar -p 1080
MockServer écoute alors sur le port 1080.
Vous configurez ensuite des attentes via son API REST ou depuis votre code. Pour les projets Node.js, utilisez le wrapper officiel :
npm install mockserver-node
const mockserver = require('mockserver-node');
mockserver.start_mockserver({
serverPort: 1080,
});
MockServer permet notamment de simuler :
- des réponses spécifiques selon les en-têtes ;
- des erreurs HTTP ;
- des délais pour tester les timeouts ;
- des corps de requête précis ;
- des échecs réseau ou applicatifs.
Idéal pour : les tests d'intégration nécessitant un contrôle fin sur les requêtes et les réponses. MockServer est sous licence Apache-2.0 et prend en charge HTTP, HTTPS et d'autres protocoles sur un seul port.
Limite à connaître : c'est un outil JVM, donc plus lourd et plus lent à démarrer que les options Node. La définition des attentes est aussi plus verbeuse qu'un simple serveur basé sur OpenAPI. Si vous comparez d'autres approches, consultez les alternatives à MockServer.
WireMock autonome
WireMock est un serveur de maquette JVM largement utilisé dans les projets Java. Son jar autonome utilise le même moteur que celui intégrable dans des tests JUnit, ce qui facilite le partage des stubs entre le développement local et la suite de tests.
Démarrez WireMock :
java -jar wiremock-standalone.jar --port 8080
Le serveur écoute sur le port 8080.
WireMock charge des stubs depuis un répertoire mappings/ ou via son API JSON. Exemple de structure :
.
├── mappings/
│ └── get-user.json
└── __files/
└── user-response.json
WireMock peut aussi enregistrer le trafic d'une API réelle et le rejouer sous forme de stubs. C'est utile pour simuler une API tierce que vous ne contrôlez pas.
Une image Docker officielle est également disponible :
wiremock/wiremock
Idéal pour : les équipes JVM qui veulent utiliser le même moteur de maquette en local et dans leurs tests, avec des fonctions d'enregistrement et de relecture. WireMock est sous licence Apache-2.0.
Limite à connaître : comme MockServer, WireMock nécessite Java et démarre plus lentement que les outils Node. Son format de mapping JSON est puissant, mais demande plus d'apprentissage qu'un fichier de données unique. Pour une approche davantage orientée navigateur, consultez les alternatives à Mock Service Worker (MSW).
Apidog CLI
Les outils précédents répondent chacun à un besoin spécifique. Apidog adopte une approche intégrée : conception de l'API, maquette, tests et documentation sont regroupés dans le même projet, et l'Apidog CLI permet de piloter ce projet depuis le terminal.
Apidog n'est pas open source : c'est un produit commercial avec un niveau gratuit. Ce niveau gratuit et la CLI permettent toutefois de centraliser des tâches qui nécessiteraient autrement un serveur de maquette, un outil de tests et un outil de spécification séparés.
Apidog génère automatiquement une maquette pour les endpoints définis dans votre projet. Les réponses suivent les types et les noms de champs de vos schémas : un champ phone peut ainsi renvoyer un numéro de téléphone plausible plutôt qu'une chaîne aléatoire.
Installez et initialisez la CLI :
npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog mock --help
Le groupe de commandes mock permet de gérer les attentes de maquette depuis des scripts ou votre CI, au même titre que les endpoints, schémas, environnements et exécutions de tests.
La sortie est structurée en JSON et inclut un champ agentHints.nextSteps, ce qui facilite son utilisation dans des scripts et par des agents IA. Consultez le guide complet de l'Apidog CLI pour la liste complète des commandes.
Idéal pour : les équipes qui veulent gérer maquette, spécification et tests dans un seul projet. Téléchargez Apidog pour essayer le serveur de maquette intégré et la CLI sur votre projet.
Limite à connaître : Apidog est une plateforme et non un binaire jetable. Il nécessite un projet et une connexion, là où json-server peut démarrer uniquement avec un fichier JSON. Si vous avez seulement besoin d'une maquette locale temporaire, un outil plus léger sera plus adapté.
Comment choisir
Choisissez selon ce que vous possédez déjà :
- Vous avez une spécification OpenAPI : utilisez Prism ou Mockoon CLI.
- Vous n'avez qu'un jeu de données JSON : utilisez json-server.
- Vous devez faire correspondre précisément les requêtes : utilisez MockServer ou WireMock.
- Vous voulez réunir conception, maquette et tests : utilisez Apidog.
| Outil | Idéal pour | Installation | Open source ? | Notes |
|---|---|---|---|---|
| Prism | Servir une spécification OpenAPI comme maquette | npx @stoplight/prism-cli |
Oui, Apache-2.0 | Fidèle au contrat, sans état, port 4010 |
| Mockoon CLI | Exécuter sans interface des maquettes créées via GUI | npx @mockoon/cli |
Oui, MIT | Lit un fichier d'environnement ou OpenAPI, image Docker |
| json-server | Créer une API REST instantanée depuis JSON | npx json-server |
Oui, MIT | CRUD avec état, aucune spécification requise, port 3000 |
| MockServer | Faire correspondre les requêtes avec précision | java -jar mockserver-netty-*.jar |
Oui, Apache-2.0 | JVM, wrapper npm disponible, port 1080 |
| WireMock | Partager un moteur entre développement et tests JVM | java -jar wiremock-standalone.jar |
Oui, Apache-2.0 | Enregistrement/relecture, image Docker, port 8080 |
| Apidog CLI | Centraliser maquette, spécification et tests | npm install -g apidog-cli |
Non, niveau gratuit | Maquette intelligente et attentes gérées |
Règle générale :
- utilisez les outils
npxpour démarrer vite ; - utilisez les serveurs JVM lorsque vous avez besoin de règles de correspondance avancées ;
- utilisez Apidog lorsque vous préférez un flux de travail unifié plutôt que plusieurs outils distincts.
Si vous hésitez encore sur l'intérêt d'une maquette, consultez les cas d'utilisation de la maquette d'API.
En résumé
La bonne solution dépend principalement de ce que vous donnez à l'outil :
- une spécification OpenAPI pour Prism ou Mockoon CLI ;
- un fichier JSON pour json-server ;
- des règles de correspondance strictes pour MockServer ou WireMock ;
- un projet API centralisé pour Apidog.
Les six outils s'exécutent depuis le terminal et peuvent s'intégrer à une tâche CI. Commencez par l'option la plus légère qui couvre votre cas d'usage, puis ajoutez de la complexité uniquement lorsque vous avez besoin de comportements plus avancés.
Pour tester l'approche intégrée, téléchargez Apidog et générez une maquette depuis la conception de votre API.
Top comments (0)