Les meilleurs outils CLI légers pour le mocking d'API

Vous avez besoin d'une fausse API pour le développement, et vous en avez besoin dans les trente secondes. Pas un service hébergé, pas une pile Docker Compose, pas une interface graphique à parcourir. Juste une commande qui lit un fichier et commence à servir des réponses sur localhost.

C'est ce que fait un serveur de maquette (mock server) léger. Vous le pointez vers une spécification OpenAPI ou un petit fichier de données, exécutez une seule commande, et obtenez des points d'accès réalistes que votre frontend ou vos tests peuvent interroger pendant que le véritable backend est encore en construction. Les meilleurs sont livrés sous forme de binaire unique ou de package compatible npx, démarrent en moins d'une seconde et ne nécessitent presque aucune configuration. Certaines des options plus lourdes présentées ici fonctionnent sur la JVM et offrent bien plus ; elles trouvent leur place lorsque vous avez besoin d'une correspondance de requêtes avancée ou d'un comportement avec état.

Ce guide classe six outils de maquette (mockers) CLI en fonction de la simplicité de leur utilisation. Il commence par ceux que vous pouvez exécuter sans rien installer, puis couvre les serveurs JVM autonomes, et se termine par la voie intégrée via l'interface CLI d'Apidog. Chaque commande d'installation et de maquette ci-dessous a été vérifiée par rapport à la documentation officielle de chaque outil. Si vous souhaitez un champ plus large au-delà de la ligne de commande, le tour d'horizon des meilleurs outils de maquette d'API couvre également les options GUI et hébergées.

Qu'est-ce qui rend un outil de maquette CLI "léger"

La légèreté concerne l'empreinte et le frottement, pas le nombre de fonctionnalités. Lorsque vous comparez ces outils, pesez quatre éléments :

• Taille de l'installation et runtime. Un package pure-Node que vous pouvez exécuter avec npx pèse quelques mégaoctets. Un serveur JVM autonome est un fichier jar de plus de 20 Mo qui nécessite un runtime Java. Les deux sont valides ; ils se situent aux extrémités opposées de cette liste.
• Vitesse de démarrage. Un bon serveur de maquette est opérationnel avant que vous ne reveniez à votre éditeur. Les outils basés sur Node démarrent à froid en moins d'une seconde.
• Configuration jusqu'à la première réponse. Pouvez-vous passer de zéro à un point d'accès en direct avec un seul fichier et une seule commande ? Les outils les plus légers répondent oui.
• Conçu pour le terminal. Pas de compte, pas de tableau de bord, pas d'étape GUI dans la boucle. L'outil lit un fichier et le sert, et il s'intègre dans un script shell ou une tâche d'intégration continue (CI).

Les outils sont classés du plus petit et plus rapide au plus grand. Prism, Mockoon CLI et json-server sont ceux que vous pouvez exécuter avec npx sans installation globale.

Prism (Stoplight)

Prism transforme un fichier OpenAPI en un serveur de maquette (mock server) en direct avec une seule commande. Si vous avez déjà une spécification, c'est la maquette la moins exigeante de la liste ; elle lit vos paths, examples et schémas et sert des réponses qui y correspondent.

npx @stoplight/prism-cli mock ./openapi.yaml

Ceci démarre un serveur sur http://127.0.0.1:4010 avec chaque opération de votre spécification connectée. Prism renvoie l'example que vous avez défini pour une réponse, ou en génère un aléatoire valide à partir du schéma si vous ne l'avez pas fait. Il valide également les requêtes entrantes par rapport à la spécification, de sorte qu'un appel malformé reçoit un 422 approprié au lieu d'un passage silencieux. Pour une installation globale, utilisez npm install -g @stoplight/prism-cli et supprimez le npx.

Idéal pour : les équipes axées sur la spécification qui veulent que la maquette reste 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.

Limites honnêtes : Prism est sans état. Une requête POST ne persiste rien, elle ne simulera donc pas un flux créer-puis-lire. Sa maquette n'est aussi bonne que votre spécification ; des exemples maigres signifient des réponses maigres. Pour une maquette contractuellement précise, c'est exactement le but, et cela s'accorde bien avec le flux de travail des outils de maquette d'API REST.

Mockoon CLI

Mockoon CLI exécute une API de maquette à partir d'un fichier de données, soit un que vous avez exporté depuis l'application de bureau Mockoon gratuite, soit une spécification OpenAPI simple. L'application de bureau vous permet de construire des routes visuellement ; l'interface CLI exécute ce même environnement sans interface graphique (headless) en CI ou sur un serveur.

npx @mockoon/cli start --data ./mockoon-env.json --port 3000

Pointez --data vers un fichier d'environnement Mockoon ou un fichier OpenAPI JSON/YAML et il sera servi immédiatement. Si le fichier de données provient d'une ancienne version de Mockoon, l'interface CLI le migre en mémoire sans toucher à l'original. Installez-le globalement avec npm install -g @mockoon/cli si vous préférez une commande mockoon-cli persistante.

Idéal pour : les équipes qui souhaitent concevoir des maquettes dans une interface graphique mais les exécuter sans interface. Il est sous licence MIT et dispose d'une image Docker officielle pour les déploiements.

Limites honnêtes : les routes les plus riches sont construites dans l'application de bureau, donc l'édition manuelle du fichier d'environnement JSON est délicate. Si vous ne voulez pas d'application compagnon du tout, Prism ou json-server conservent tout dans un seul fichier que vous écrivez à la main.

json-server

json-server est le moyen le plus rapide de simuler une API REST lorsque vous n'avez pas encore de spécification. Vous écrivez un simple fichier JSON décrivant vos données, et il génère une API REST complète autour de celles-ci, avec GET, POST, PUT, PATCH et DELETE.

echo '{ "posts": [{ "id": 1, "title": "hello" }] }' > db.json
npx json-server db.json

Ceci sert http://localhost:3000/posts avec un véritable CRUD. Un POST vers /posts ajoute réellement un enregistrement et le réécrit dans db.json, vous obtenez ainsi un comportement avec état gratuitement, ce que Prism et WireMock ne vous donneront pas directement. Vous obtenez également le filtrage, le tri et la pagination via les paramètres de requête. La version 1.x actuelle surveille le fichier et se recharge par défaut en cas de modification ; installez globalement avec npm install -g json-server si vous voulez qu'il soit toujours dans votre PATH.

Idéal pour : les développeurs frontend qui ont besoin d'un backend REST fonctionnel en une minute, avant que la véritable API n'existe. Il est sous licence MIT et est l'une des options de serveurs de maquette légers pour une API RESTful qui ne nécessite aucune spécification.

Limites honnêtes : il suppose une forme REST de type ressource. Les routes profondément personnalisées, les points de terminaison non REST ou la correspondance stricte des en-têtes ne correspondent pas à ce qu'il fait proprement. C'est un outil de prototypage, pas un validateur de contrat.

MockServer

MockServer est le poids lourd pour la correspondance de requêtes précise. Là où les outils ci-dessus servent une spécification ou un fichier de données, MockServer vous permet de définir des attentes : faire correspondre une requête par méthode, chemin, en-tête, requête ou corps, puis renvoyer exactement la réponse souhaitée, y compris les délais et les échecs pour tester les timeouts et la gestion des erreurs.

java -jar mockserver-netty-5.15.0-no-dependencies.jar -p 1080

Ceci démarre MockServer sur le port 1080. Vous envoyez ensuite des attentes à son API REST pour configurer le comportement, ou le pilotez de manière programmatique. Les utilisateurs de Node peuvent ignorer le jar brut et utiliser le wrapper officiel :

npm install mockserver-node

const mockserver = require('mockserver-node');
mockserver.start_mockserver({ serverPort: 1080 });

Idéal pour : les tests d'intégration qui nécessitent un contrôle précis sur l'apparence d'une requête et la manière dont la maquette y répond. Il est sous licence Apache-2.0 et prend en charge HTTP, HTTPS et plus encore sur un seul port.

Limites honnêtes : c'est un serveur JVM, il est donc plus lourd et plus lent à démarrer que les outils Node, et la configuration des attentes est plus verbeuse que de pointer vers une spécification. Si vous avez juste besoin qu'une spécification soit servie, c'est excessif ; si vous le dépassez, la comparaison des alternatives à MockServer expose les compromis.

WireMock (autonome)

WireMock est l'autre serveur de maquette JVM établi, populaire dans le monde des tests Java et JVM. Son jar autonome exécute le même moteur que vous intégreriez dans un test JUnit, de sorte qu'une maquette que vous construisez en développement local est directement réutilisable dans votre suite de tests.

java -jar wiremock-standalone.jar --port 8080

Ceci sert sur le port 8080. WireMock lit les mappages de stubs depuis un répertoire mappings/ ou son API JSON, et il peut également enregistrer le trafic réel et le rejouer comme stubs, ce qui est pratique lorsque vous simulez une API tierce que vous ne contrôlez pas. Il existe une image Docker officielle wiremock/wiremock pour l'intégration continue (CI).

Idéal pour : les équipes JVM qui souhaitent un moteur de maquette unique partagé entre le développement local et leur suite de tests, ainsi que l'enregistrement et la relecture. Il est sous licence Apache-2.0.

Limites honnêtes : comme MockServer, il nécessite un runtime Java et démarre plus lentement que les options Node. Son JSON de mappage de stubs est puissant mais plus complexe à apprendre qu'une maquette de données à fichier unique. Si vous venez du côté JavaScript, la comparaison des alternatives à Mock Service Worker (MSW) couvre la place de WireMock par rapport à la maquette axée sur le navigateur.

Apidog CLI

Les outils ci-dessus résolvent chacun une facette de la maquette. Apidog adopte une approche intégrée : la conception de votre API, la maquette, vos tests et votre documentation vivent dans un seul projet, et l'Apidog CLI pilote ce projet depuis le terminal. Apidog n'est pas open source ; c'est un produit commercial avec un niveau gratuit. Mais ce niveau gratuit, plus l'interface CLI, vous offre une alternative à l'assemblage d'un serveur de maquette, d'un exécuteur de tests et d'un outil de spécification distincts.

Apidog génère automatiquement une maquette intelligente pour chaque point de terminaison que vous définissez, avec des réponses qui suivent les types et les noms de champs de votre schéma, de sorte qu'un champ phone renvoie un numéro de téléphone plausible plutôt qu'une chaîne aléatoire. Lorsque vous avez besoin d'une réponse spécifique pour une requête spécifique, vous ajoutez une attente de maquette. L'interface CLI gère ces ressources de maquette dans le cadre du projet :

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog mock --help

Le groupe de commandes mock fonctionne avec les attentes de maquette de votre projet à partir de scripts et d'intégration continue (CI), aux côtés des groupes de commandes pour les points de terminaison, les schémas, les environnements et les exécutions de tests. La sortie est un JSON structuré avec un champ agentHints.nextSteps, ce qui le rend utilisable par les agents IA ainsi que par les humains. La surface complète des commandes est couverte dans le guide complet de l'Apidog CLI.

Idéal pour : les équipes qui préfèrent conserver la maquette, la spécification et les tests au même endroit plutôt que d'exécuter trois outils distincts. Téléchargez Apidog pour essayer le serveur de maquette intégré et l'interface CLI sur votre propre projet.

Limites honnêtes : c'est une plateforme, pas un binaire à usage unique, elle demande donc un projet et une connexion là où json-server ne demande rien. Si tout ce dont vous avez besoin est une maquette jetable à partir d'un seul fichier, un outil plus léger l'emporte ; si vous concevez déjà votre API dans Apidog, la maquette est déjà là.

Comment choisir

Adaptez l'outil à ce que vous avez déjà. Si vous avez une spécification OpenAPI, Prism ou Mockoon CLI la servent directement. Si vous n'avez encore rien, json-server invente une API à partir d'un fichier JSON. Si vous avez besoin d'une correspondance exacte des requêtes, optez pour MockServer ou WireMock. Si vous souhaitez que la maquette cohabite avec votre conception et vos tests, utilisez Apidog.

La règle générale : les outils npx pour la vitesse, les serveurs JVM pour la profondeur de correspondance, Apidog lorsque vous voulez un seul flux de travail au lieu de plusieurs. Si vous hésitez encore à utiliser une maquette, le guide des cas d'utilisation de la maquette d'API explique quand cela en vaut la peine.

En résumé

La maquette légère se résume à une question : qu'avez-vous déjà à donner à l'outil ? Une spécification va à Prism ou Mockoon CLI. Une page blanche va à json-server. Une correspondance stricte va à MockServer ou WireMock. Et si vous préférez ne pas exécuter et connecter plusieurs outils, Apidog garde la maquette à côté de la conception et des tests, pilotée par la même interface CLI que vous utiliseriez de toute façon.

Les six s'exécutent depuis le terminal, s'intègrent dans une tâche d'intégration continue (CI) et vous procurent une fausse API en quelques secondes au lieu d'heures. Choisissez le plus petit qui couvre votre cas, et n'ajoutez du poids que lorsque vous en avez réellement besoin. Pour voir la version intégrée, Téléchargez Apidog et générez un serveur de maquette à partir de la conception de votre API en une seule étape.