Comment simuler une API sur Apidog sans écrire une ligne de code

Votre équipe frontend est bloquée. Le backend pour GET /users et GET /orders n'est pas prêt, mais l'interface utilisateur a besoin de données réalistes pour afficher des listes, paginer et gérer les états vides. L'ancienne solution consistait à écrire manuellement un faux fichier JSON et à le servir, puis à le modifier à chaque fois qu'un champ change. Ce travail est fastidieux et il se désynchronise presque immédiatement de la vraie API.

Il existe un chemin plus rapide. Si vous avez déjà une spécification d'API, Apidog peut générer un mock fonctionnel directement à partir du schéma de l'endpoint, sans configuration ni code. Cette fonctionnalité s'appelle Smart Mock, et elle lit les noms et types de vos champs pour produire des données qui semblent réelles : un champ name renvoie un nom plausible, un champ email renvoie un e-mail plausible. Ce guide vous expliquera comment simuler deux endpoints e-commerce de bout en bout, vous montrera où se trouve l'URL de mock, expliquera l'ordre de priorité qui détermine quelle réponse l'emporte, et couvrira ce qu'il faut faire lorsque Smart Mock se trompe. Si vous souhaitez d'abord une introduction plus large au concept, notre aperçu de ce qu'est le mocking d'API et comment il fonctionne prépare le terrain, et le site JSON Schema explique le modèle de contraintes que Smart Mock respecte.

bouton

Ce que Smart Mock fait et pourquoi il vous fait gagner du temps

Le moteur de mock d'Apidog peut faire cinq choses, selon la documentation. Il peut renvoyer des données générées automatiquement à partir de votre spécification d'API, ce qui est Smart Mock. Il peut renvoyer l'exemple de réponse que vous avez défini dans la spécification. Il peut renvoyer une réponse personnalisée spécifiée. Il peut renvoyer différentes réponses basées sur les paramètres de requête, ce qui est le mocking conditionnel. Et il peut renvoyer des réponses dont les valeurs sont liées à la requête via des scripts de mock.

Smart Mock est le membre sans configuration de cette famille, et il est intégré à Apidog aux côtés des outils de conception, de débogage et de test. Vous ne définissez pas de corps d'exemple et vous n'écrivez pas de règles. Tant qu'un endpoint a un schéma de réponse spécifié, Smart Mock lit ce schéma et remplit chaque champ avec des valeurs réalistes. Il agit comme un mécanisme de repli automatique : tout endpoint qui manque d'un exemple prédéfini renvoie quand même quelque chose de sensé, de sorte qu'aucune requête ne reste vide.

Pour un frontend bloqué, c'est toute la solution. Vous importez ou concevez votre API une seule fois, et chaque endpoint devient un mock fonctionnel la minute suivante. Lorsque le schéma change, le mock change avec lui, car tous deux lisent la même source.

Avant de commencer : la seule exigence

Smart Mock nécessite une réponse spécifiée sur l'endpoint. C'est le seul prérequis. Si vous avez conçu l'API dans Apidog, ajoutez un schéma de réponse sous la définition de réponse de l'endpoint. Si vous avez importé un fichier OpenAPI, les schémas de réponse l'accompagnent généralement. Sans réponse définie, le moteur n'a rien à lire, et le mock ne renvoie rien d'utile.

Vous aurez également besoin du client de bureau Apidog si vous prévoyez d'utiliser Local Mock, car il s'exécute sur votre propre machine et n'est pas disponible dans Apidog Web. Téléchargez Apidog pour suivre. C'est gratuit et aucune carte de crédit n'est requise.

Pas à pas : simuler GET /users et GET /orders

Construisons un mock pour une petite API de magasin. Nous allons définir deux endpoints et les appeler tous les deux.

Étape 1 : définir les endpoints et leurs schémas de réponse

Créez GET /users avec un corps de réponse comme ceci :

{
  "id": 1024,
  "name": "Amara Osei",
  "email": "amara.osei@example.com",
  "phone": "+1-415-555-0148",
  "createdAt": "2026-03-11T09:24:00Z",
  "isActive": true
}

Puis créez GET /orders, renvoyant une liste :

[
  {
    "orderId": "ORD-58210",
    "userId": 1024,
    "total": 84.50,
    "currency": "USD",
    "status": "shipped",
    "createdAt": "2026-05-02T14:03:00Z"
  }
]

Assurez-vous que chaque propriété a un type dans le schéma. Les types et les noms sont ce que Smart Mock utilise pour choisir de bonnes valeurs.

Étape 2 : trouver et copier l'URL de mock

Chaque endpoint obtient automatiquement une URL de mock. L'endroit où vous la trouvez dépend du mode dans lequel vous êtes :

En mode DESIGN, l'URL de mock se trouve dans l'onglet API sous l'endpoint.
En mode DEBUG, elle se trouve dans l'onglet Mock.

Cliquez sur "Cliquer pour copier" pour la récupérer. Une chose à noter : cela ne copie que l'URL. Si votre endpoint utilise une méthode autre que GET, ou nécessite un corps de requête, vous ajoutez vous-même la méthode et le corps lorsque vous l'appelez.

Une URL de Local Mock s'exécute sur 127.0.0.1 port 4523 et ressemble à ceci en mode chemin :

http://127.0.0.1:4523/m1/{projectID}-{versionNo}-{serverNo}/users

Local Mock démarre automatiquement tant que le client Apidog est ouvert. Il existe également une forme en mode ID qui cible un endpoint par son ID :

http://127.0.0.1:4523/m2/{projectID}-{versionNo}-{serverNo}/{endpointId}

Étape 3 : appeler le mock

Appelez l'URL avec curl :

curl http://127.0.0.1:4523/m1/1234567-0-0/users

Vous obtenez quelque chose comme ceci, généré à partir de votre schéma :

{
  "id": 3187,
  "name": "Diego Marchetti",
  "email": "diego.marchetti@example.net",
  "phone": "+1-628-555-0113",
  "createdAt": "2026-01-27T18:41:22Z",
  "isActive": true
}

Remarquez que le name ressemble à un nom et que l'email ressemble à un e-mail. C'est la correspondance des noms de propriétés (Property Name Matching) qui est à l'œuvre, pas un bruit aléatoire. Actualisez la requête et les valeurs dynamiques se régénèrent, de sorte que chaque appel vous donne de nouvelles données. C'est utile pour tester la manière dont votre interface utilisateur gère des contenus variés.

Appelez l'endpoint des commandes de la même manière :

curl http://127.0.0.1:4523/m1/1234567-0-0/orders

Vous obtenez un tableau d'objets de commande avec des totaux, des statuts et des horodatages réalistes, prêts pour votre vue de liste de commandes.

Comment Smart Mock décide de chaque valeur

Lorsque Smart Mock remplit une seule propriété, il fonctionne selon une priorité de génération de données à trois niveaux. Comprendre cet ordre vous indique exactement comment orienter la sortie.

Champ de Mock (Mock Field). Si vous définissez une valeur ou une expression personnalisée sur la propriété dans la spécification de réponse, celle-ci l'emporte. Le champ de Mock prend deux types d'entrée : une valeur fixe (Fixed value), qui est une valeur statique renvoyée à chaque fois, et une instruction Faker (Faker statement), qui est une expression dynamique produisant des données variées. Par exemple, définissez le champ de Mock d'un champ status sur une instruction Faker qui choisit parmi shipped, pending et delivered.
Correspondance des Noms de Propriété (Property Name Matching). Sans champ de Mock défini, Smart Mock fait correspondre le nom de la propriété à des règles intégrées utilisant des motifs génériques ou des expressions régulières, puis génère des données qui correspondent. C'est pourquoi email et createdAt apparaissent correctement. Les règles se trouvent sous Paramètres de Mock, et vous pouvez ajouter les vôtres.
Schéma JSON (JSON Schema). Si le nom ne correspond à aucune règle, Smart Mock revient à une valeur par défaut basée sur le type contraint par votre schéma. Une chaîne sans nom correspondant et sans contraintes obtient simplement une chaîne générique.

Les données générées respectent vos contraintes de schéma JSON : la longueur des chaînes, les valeurs d'énumération, les plages numériques et la longueur des tableaux sont toutes respectées. Si vous définissez status comme une énumération de trois valeurs, Smart Mock ne renvoie qu'une seule de ces trois. Si vous définissez minItems d'un tableau à 3, vous obtenez au moins trois éléments. Chaque paramètre de propriété apparaît dans les données de mock finales.

Apidog prend également en charge les locales de mock, vous pouvez donc générer des données de test dans différentes langues et formats régionaux. Si votre magasin dessert un marché japonais, changez la locale et les noms et adresses reviendront dans le bon format.

Quand Smart Mock se trompe, et comment le corriger

Smart Mock est une inférence, il peut donc parfois se tromper. Une propriété nommée sku pourrait ne correspondre à aucune règle intégrée et revenir à une chaîne générique. Un total pourrait revenir comme un nombre simple alors que vous vouliez deux décimales et une plage raisonnable. Voici comment le corriger, du moins invasif au plus contrôlé.

Resserrez d'abord le schéma. Souvent, la solution est une meilleure contrainte. Ajoutez un enum à status, un minimum et un maximum à total, ou un pattern à sku. Smart Mock respecte toutes ces contraintes, de sorte que la sortie s'ajuste à la plage sans aucune valeur personnalisée.
Définissez un champ de Mock. Lorsque le schéma seul ne peut pas exprimer ce que vous voulez, définissez le champ de Mock de la propriété. Utilisez une valeur fixe (Fixed value) lorsque le champ doit toujours renvoyer la même chose, comme une currency de USD. Utilisez une instruction Faker (Faker statement) lorsque vous voulez de la variété dans certaines limites. La couche Faker d'Apidog s'appuie sur les mêmes idées que la bibliothèque Mock.js, et notre guide sur l'utilisation de Faker dans Apidog couvre en détail la syntaxe des expressions.
Ajoutez une règle de correspondance des noms de propriétés. Si le même champ mal nommé apparaît dans de nombreux endpoints, apprenez-le une fois à Smart Mock. Allez dans Paramètres, puis Paramètres généraux, puis Paramètres de fonctionnalité, puis Paramètres de Mock. Cliquez sur Nouveau, définissez la condition qui correspond au nom de votre champ, et donnez-lui une expression de mock. Dès lors, chaque sku à travers le projet générera le motif que vous avez défini au lieu d'une chaîne générique.

La séquence de priorité de mock : ce qui l'emporte réellement

Une source de confusion courante est de savoir quelle réponse un endpoint renvoie lorsque plusieurs sont possibles. Apidog résout ce problème avec le paramètre de méthode de mock par défaut (Default mock method), trouvé dans les paramètres du projet (Project Settings) sous Paramètres de Mock (Mock Settings). Il a deux options :

Smart Mock en premier (par défaut) donne la séquence : Attente de Mock (Mock Expectation), puis Smart Mock.
Exemple de réponse en premier donne la séquence : Attente de Mock (Mock Expectation), puis Exemple de Réponse (Response Example), puis Smart Mock.

Lisez-les de gauche à droite. Par défaut, une requête vérifie s'il existe une attente de Mock correspondante, et si aucune ne correspond, Smart Mock génère le corps. Passez à "Exemple de réponse en premier" et un exemple de réponse défini est vérifié avant que Smart Mock ne serve de repli.

Une règle se situe au-dessus des deux séquences : les attentes de Mock (Mock Expectations) ont toujours la première priorité lorsqu'elles sont configurées et que leurs conditions correspondent, quelle que soit la séquence que vous avez choisie. Donc, si vous configurez une réponse conditionnelle qui renvoie un 404 lorsque userId est 9999, cette attente sera déclenchée indépendamment de la méthode de mock par défaut. Pour une explication complète des réponses basées sur les paramètres, consultez notre guide sur le mocking de réponses API conditionnelles dans Apidog.

En résumé pratique : les attentes de Mock (Mock Expectations) personnalisées l'emportent sur tout, puis soit Smart Mock, soit l'exemple de réponse (Response Example), selon votre réglage. Smart Mock est toujours le repli de dernier recours, c'est pourquoi chaque requête reçoit une réponse.

Mock Local, Cloud et Runner : où s'exécute le mock

Smart Mock et Custom Mock décrivent comment une réponse est générée. L'endroit où ce mock est hébergé est un choix distinct, et Apidog vous offre trois options :

Mock Local (Local Mock) s'exécute sur votre ordinateur via le client Apidog. Il démarre automatiquement et n'est accessible que lorsque le client est ouvert. Il écoute sur 127.0.0.1:4523, donc pour un autre appareil sur votre réseau, vous avez besoin de l'adresse IP LAN de votre machine. Il n'est pas disponible dans Apidog Web.
Mock Cloud (Cloud Mock) est hébergé sur les serveurs d'Apidog et accessible 24h/24 et 7j/7. Il est désactivé par défaut, activez-le donc dans la gestion de l'environnement lorsque vous souhaitez qu'un coéquipier ou un aperçu déployé puisse atteindre le mock. Ses URL utilisent https://mock.apidog.com avec la même structure de chemin m1/m2, et elles sont destinées aux tests, pas au trafic de production.
Mock Runner (Runner Mock) est auto-hébergé sur l'infrastructure de votre propre équipe et partagé au sein de l'équipe, ce qui convient à un environnement interne où le mock doit se trouver derrière votre propre réseau.

Choisissez Local Mock pour le travail frontend individuel, Cloud Mock lorsque d'autres doivent y accéder, et Runner Mock lorsque le mock doit résider sur vos propres serveurs. Si vous comparez les options hébergées à d'autres services, notre comparaison des outils de mocking API en ligne les met côte à côte, et le guide Apidog Cloud Mock couvre la configuration hébergée en détail.

Quelques pièges de routage à connaître

Le routage des mocks a quelques règles qui peuvent dérouter.

Les chemins des endpoints doivent commencer par un /. Un chemin comme /orders est correctement acheminé via l'environnement de mock. Une URL complète qui ne commence pas par / n'utilisera pas du tout l'environnement de mock, et un chemin sans slash initial ne fonctionne qu'en mode ID.

Si deux API partagent la même méthode et le même chemin, le mode chemin ne peut pas les distinguer seul. Ajoutez un paramètre de requête ?apidogApiId={endpointId} pour pointer vers l'endpoint exact que vous souhaitez.

Et n'oubliez pas le comportement d'actualisation : les données de mock se mettent à jour lorsque vous actualisez la requête. Chaque actualisation régénère les valeurs dynamiques, donc si vous voyez la même réponse deux fois, vous regardez probablement une vue mise en cache plutôt qu'un nouvel appel.

Automatisez le flux de travail avec l'interface de ligne de commande Apidog (CLI)

Le mocking lui-même est une capacité graphique et cloud dans Apidog. Le moteur de mock, qu'il soit Local, Cloud ou Runner, sert les réponses ; l'interface de ligne de commande Apidog (CLI) n'héberge ni ne démarre de serveur de mock depuis le terminal. Ce que la CLI ajoute est un moyen de maintenir la justesse du schéma derrière vos mocks au fur et à mesure que le projet évolue.

Parce que Smart Mock génère sa sortie à partir du schéma d'endpoint, le mock n'est aussi bon que la spécification. L'interface de ligne de commande Apidog (CLI), et les agents de codage IA comme Cursor, Claude Code, Trae et Codex travaillant via celle-ci, peuvent créer et mettre à jour les endpoints et les schémas dans votre projet. Cela maintient la précision de la sortie du mock chaque fois que le contrat change, sans que personne n'ait à ouvrir l'application pour éditer manuellement les champs.

Ensuite, une fois que le mock a débloqué le travail frontend, les scénarios de test du même projet s'exécutent sans interface graphique (headless) en CI pour vérifier le backend réel par rapport au même contrat que le mock a décrit. C'est une seule commande :

apidog run -t <scenario_id> -e <env_id> -r html,cli

Installez avec npm install -g apidog-cli (Node.js v16 ou ultérieur), authentifiez-vous avec apidog login --with-token <your-token>, et vous pouvez intégrer cela dans n'importe quel pipeline. Notre guide sur l'exécution d'Apidog dans un pipeline CI/CD décrit la configuration. Le mock maintient le frontend en mouvement ; la CLI garantit la conformité du backend par rapport à la même source de vérité.

FAQ

Dois-je écrire du code pour utiliser Smart Mock ? Non. Tant qu'un endpoint a un schéma de réponse spécifié, Smart Mock génère automatiquement des données réalistes. Vous n'avez recours au code, à une instruction Faker ou à un script de mock que lorsque vous souhaitez remplacer un champ spécifique. Consultez l'aperçu de l'API de mock pour les concepts.

Pourquoi mon URL de mock ne renvoie rien ? La cause la plus courante est une définition de réponse manquante sur l'endpoint. Smart Mock lit le schéma de réponse, alors ajoutez-en un d'abord. Vérifiez également que votre chemin commence par un / et, si vous utilisez Local Mock, que le client Apidog est ouvert.

Comment faire en sorte que Smart Mock renvoie une valeur spécifique au lieu d'une valeur aléatoire ? Définissez le champ de Mock de la propriété. Une valeur fixe (Fixed value) renvoie la même chose à chaque fois ; une instruction Faker (Faker statement) renvoie des données variées mais contrôlées. Le champ de Mock se situe au sommet de la priorité à trois niveaux de Smart Mock, il l'emporte donc toujours sur la correspondance des noms et les valeurs par défaut du schéma.

Les coéquipiers peuvent-ils atteindre un mock s'exécutant sur mon ordinateur portable ? Uniquement via votre réseau local, et uniquement tant que le client Apidog est ouvert, car Local Mock écoute sur 127.0.0.1:4523. Pour un accès permanent, activez Cloud Mock, qui est désactivé par défaut et hébergé sur https://mock.apidog.com.

Quelle réponse l'emporte si j'ai à la fois un exemple et Smart Mock ? Cela dépend de la méthode de mock par défaut (Default mock method). Avec "Smart Mock en premier", Smart Mock génère le corps. Avec "Exemple de réponse en premier", votre exemple de réponse est utilisé avant Smart Mock. Dans tous les cas, une attente de Mock correspondante l'emporte sur les deux.

En résumé

Smart Mock transforme un schéma d'API en un mock fonctionnel sans code et sans configuration, ce qui est exactement ce dont un frontend bloqué a besoin. Définissez votre réponse, copiez l'URL de mock depuis l'onglet API ou l'onglet Mock, et appelez-la ; lorsque les suppositions nécessitent d'être ajustées, resserrez le schéma ou définissez un champ de Mock, et rappelez-vous que les attentes de Mock l'emportent toujours. Téléchargez Apidog et simulez votre premier endpoint dans le temps qu'il faut pour lire cette phrase.

bouton