Votre équipe frontend est bloquée. La conception est validée, les écrans sont à moitié construits, et le seul obstacle est une API qui n'existe pas encore. Le backend est encore à un sprint de distance, donc l'interface utilisateur n'a rien de réel à appeler. La solution temporaire habituelle est une simulation locale, et elle fonctionne jusqu'au moment où vous fermez votre ordinateur portable. Ensuite, le point de terminaison que votre coéquipier dans un autre fuseau horaire utilisait devient inaccessible.
C'est cette lacune qu'Apidog comble avec Cloud Mock. Au lieu d'une simulation qui vit et meurt sur une seule machine, vous obtenez une URL publique hébergée sur mock.apidog.com qui reste active 24 heures sur 24. Les développeurs frontend, QA et partenaires peuvent tous utiliser des points de terminaison réalistes avant qu'une seule ligne de code backend ne soit déployée. Si vous souhaitez avoir une vue d'ensemble de ce qu'apporte la simulation à une équipe, notre introduction sur ce qu'est une simulation d'API et quand l'utiliser pose les bases. Pour les mécanismes de l'intégration d'une URL de simulation publique dans la gestion des requêtes, la référence MDN sur le modèle requête/réponse HTTP est un excellent rappel.
bouton
Qu'est-ce que Cloud Mock et pourquoi les simulations locales sont-elles insuffisantes ?
Apidog génère un point de terminaison de simulation pour chaque API que vous concevez. Par défaut, cette simulation est locale : elle s'exécute à partir de votre instance Apidog et répond tant que votre machine est allumée. Dès que vous l'arrêtez, le point de terminaison cesse de répondre. C'est suffisant pour le débogage individuel. Mais cela s'effondre dès que quelqu'un d'autre dépend de l'URL.
Cloud Mock est la solution. C'est un point de terminaison de simulation disponible en permanence qui persiste indépendamment de toute machine individuelle. Les ordinateurs de vos coéquipiers peuvent être en veille, votre ordinateur portable peut être dans un sac, et la simulation cloud continue de répondre aux requêtes 24h/24 et 7j/7. Le point de terminaison est hébergé sur le service d'Apidog, de sorte que la disponibilité n'est pas liée à la présence en ligne de quiconque.
Le bénéfice concret est un transfert de responsabilités fluide. Vous concevez le contrat, activez Cloud Mock et partagez une seule URL. Le frontend se construit avec des données réalistes, l'assurance qualité rédige des cas de test basés sur des formes de réponse réelles, et un partenaire qui s'intègre avec vous peut commencer à connecter son client immédiatement. Personne n'attend le backend, et personne ne vous attend pour maintenir un processus en cours d'exécution. Si vous coordonnez cela à travers différentes régions, les modèles de partage de serveurs de simulation et d'environnements avec des équipes mondiales approfondissent le flux de travail.
Activer Cloud Mock et obtenir votre URL publique
Examinons cela avec une API réaliste. Supposons que vous construisiez un service `users` avec un point de terminaison `GET /users` qui renvoie une liste d'enregistrements clients. Voici comment transformer cela en un point de terminaison cloud partageable.
Étape 1 : Activer Cloud Mock
Ouvrez votre projet et allez dans Paramètres du projet > Paramètres des fonctionnalités > Paramètres de simulation. Activez Cloud Mock. C'est l'interrupteur qui indique à Apidog d'héberger vos simulations sur son service toujours actif plutôt que de les servir uniquement localement.
Vous ne le faites qu'une seule fois par projet. Une fois activé, chaque point de terminaison du projet obtient une URL de simulation cloud en plus de son URL locale.
Étape 2 : Copier l'URL de simulation cloud
Ouvrez le point de terminaison que vous souhaitez partager, `GET /users` dans ce cas. Allez dans son onglet Mock et copiez l'URL Cloud Mock. Vous obtiendrez quelque chose de cette forme :
https://mock.apidog.com/m1/2689726-0-default/users?apidogToken=GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi
La structure du chemin suit un modèle : `mock.apidog.com/m1/<projectId>-<num>-<env>/<path>`. Apidog le construit pour vous, vous n'avez donc pas à l'assembler manuellement. Notez que la documentation le montre par exemple plutôt que de publier un modèle fixe, alors traitez l'URL copiée comme la source de vérité plutôt que d'essayer d'en construire une vous-même.
Étape 3 : Tester la simulation instantanément dans Apidog
Avant de transmettre l'URL à qui que ce soit, confirmez qu'elle renvoie ce que vous attendez. Sur le même onglet Mock, envoyez une requête de test à l'URL de simulation. Apidog envoie la requête et vous montre la réponse directement. Vous obtenez une lecture instantanée de la pertinence des données générées.
Une simulation `GET /users` pourrait renvoyer ceci :
[
{
"id": 1,
"name": "Amelia Turner",
"email": "amelia.turner@example.com",
"city": "Portland"
},
{
"id": 2,
"name": "Marcus Bell",
"email": "marcus.bell@example.com",
"city": "Austin"
}
]
Ces valeurs ne sont pas codées en dur. Apidog lit les noms et types de champs de votre schéma et génère des données plausibles correspondantes, ce qui rend la simulation utile pour un frontend affichant un tableau d'apparence réelle.
Étape 4 : Ouvrir l'URL dans un navigateur
Pour une requête GET, l'URL de simulation cloud fonctionne directement dans un navigateur web. Collez-la dans la barre d'adresse et vous verrez la réponse JSON. C'est la vérification la plus rapide que vous pouvez donner à une partie prenante non technique : pas de client, pas de curl, seulement un lien qui renvoie des données.
Pour tout ce qui dépasse un rapide coup d'œil, votre frontend l'appelle comme n'importe quel autre point de terminaison :
curl "https://mock.apidog.com/m1/2689726-0-default/users?apidogToken=GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi"
C'est le processus complet. Concevez le point de terminaison, activez Cloud Mock, copiez l'URL, et votre équipe est débloquée.
Sécuriser la simulation avec l'authentification par jeton
Une URL publique est pratique, et parfois trop pratique. Si votre simulation reflète une fonctionnalité non encore publiée ou une intégration partenaire que vous préférez ne pas exposer, vous pouvez la protéger.
Allez dans Paramètres du projet > Paramètres des fonctionnalités > Paramètres de simulation et définissez la permission d'accès sur Authentification par jeton. Une fois cela activé, chaque requête doit contenir un `apidogToken` valide, et les requêtes sans jeton sont rejetées. Vous pouvez fournir le jeton de trois manières :
Comme paramètre de chaîne de requête URL, ce que l'URL copiée utilise déjà :
curl "https://mock.apidog.com/m1/2689726-0-default/users?apidogToken=GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi"
Comme en-tête de requête, ce qui garde le jeton hors de l'URL et des journaux du serveur :
curl "https://mock.apidog.com/m1/2689726-0-default/users" \
-H "apidogToken: GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi"
Ou comme paramètre de corps de requête nommé `apidogToken` dans une requête `form-data` ou `x-www-form-urlencoded`, ce qui convient aux clients qui publient des corps de formulaire.
Pour le code frontend, l'approche par en-tête est généralement la plus propre. Elle maintient le jeton hors de tout ce qui journalise les URLs complètes, et elle sépare l'identifiant du chemin de la ressource :
const res = await fetch(
"https://mock.apidog.com/m1/2689726-0-default/users",
{ headers: { apidogToken: "GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi" } }
);
const users = await res.json();
Une chose à prévoir : si vous activez l'authentification par jeton après avoir déjà partagé une URL simple, chaque consommateur devra ajouter le jeton, sinon ses appels commenceront à échouer. Coordonnez le changement pour que l'assurance qualité et les partenaires ne se retrouvent pas face à des requêtes rejetées.
Générer des données réalistes et régionales avec les locales
Une simulation qui renvoie `"name": "string"` pour chaque enregistrement n'apprend rien à votre interface utilisateur. Une simulation qui renvoie des noms, adresses et numéros de téléphone d'apparence réelle permet au frontend de détecter les bogues de mise en page, les débordements de texte et les problèmes de formatage avant même l'arrivée des données réelles. Apidog gère cela avec Faker.js en arrière-plan, et les contrôles de locale deviennent véritablement utiles pour les produits internationaux.
Comment fonctionne la locale par défaut
Par défaut, Faker suit le paramètre de langue de votre projet. Cela est configuré dans Paramètres du projet > Paramètres de base, et quelle que soit la langue que vous choisissez, elle devient la locale par défaut pour toutes les valeurs de simulation générées. Configurez le projet en français et vos noms et adresses simulés auront des accents français sans aucun travail champ par champ.
Surcharger la locale pour l'ensemble du projet
Si vous souhaitez des données de simulation dans une locale spécifique différente de la langue du projet, vous pouvez la surcharger. Allez dans Paramètres du projet > Paramètres des fonctionnalités > Paramètres de simulation et choisissez une locale Faker dans la liste déroulante. Cette surcharge l'emporte sur le paramètre de langue par défaut des Paramètres de base pour chaque champ du projet.
C'est pratique lorsque vous testez l'internationalisation. Orientez la locale du projet vers le Japon et chaque adresse, nom et numéro de téléphone généré reflétera cette région, vous permettant de voir comment votre interface utilisateur se comporte face aux scripts non latins et aux différents formats d'adresse. L'auto-génération de ce type de données sensibles au schéma est un sujet en soi, et la présentation sur le smart mock d'Apidog et comment il lit votre schéma couvre l'aspect génération en détail.
Surcharger la locale champ par champ
Parfois, vous avez besoin qu'un champ soit dans une locale différente des autres, par exemple une liste de clients qui mélange les régions. Vous pouvez définir la locale directement dans l'expression de simulation en utilisant le `paramètre locale` :
{{$person.fullName(locale='ja')}}
Cela produira des noms japonais comme `田中 太郎` uniquement pour ce champ, tandis que le reste de la réponse suivra la locale du projet. La précédence se déroule sur trois niveaux : une locale au niveau du champ annule la locale au niveau du projet, qui annule le paramètre de langue par défaut des Paramètres de base. Vous définissez donc une valeur par défaut de projet judicieuse et n'optez pour des surcharges au niveau du champ que lorsque vous avez réellement besoin de l'exception.
Une note honnête et rapide sur la portée : la documentation montre `ja` comme exemple pratique et ne publie pas une liste complète des locales prises en charge, alors confirmez le code exact pour votre région cible dans la documentation de simulation Apidog avant de vous y fier. Les conventions de Faker sont documentées dans la référence de locale Faker.js.
Faire correspondre le fuseau horaire également
Il existe un contrôle parallèle pour le temps. Une valeur par défaut au niveau du projet se trouve dans Paramètres du projet > Paramètres des fonctionnalités > Paramètres de simulation, et vous pouvez la surcharger par champ avec le `paramètre timeZone` à l'intérieur d'une expression de simulation. Si votre interface utilisateur affiche des horodatages, cela maintient les valeurs `createdAt` générées cohérentes avec la région que vous simulez plutôt que de revenir au fuseau horaire de votre serveur.
Entre les contrôles de locale et de fuseau horaire, vous pouvez créer une simulation qui imite de manière convaincante une base d'utilisateurs japonaise, allemande ou une cohorte internationale mixte, le tout à partir du même schéma de point de terminaison. Pour l'ensemble plus large de scénarios que cela débloque, le récapitulatif des cas d'utilisation pratiques de la simulation d'API mérite d'être consulté.
Cloud Mock versus une simulation auto-hébergée
Cloud Mock est l'option hébergée d'Apidog, et elle convient à la plupart des équipes. Si votre organisation a des règles de résidence des données ou une politique interdisant le routage du trafic de test via le cloud d'un fournisseur, Apidog prend également en charge l'exécution du service de simulation sur votre propre infrastructure. Le compromis est simple : l'option cloud est sans configuration et toujours active, tandis que l'auto-hébergement vous donne le contrôle au prix de l'exécution du service par vous-même. Si telle est votre situation, le guide pour auto-héberger le serveur de simulation Apidog en détail. Pour les équipes qui comparent les options hébergées, la comparaison des outils de simulation d'API en ligne présente le paysage.
Concernant les restrictions de forfait, une réponse directe : les fonctionnalités Cloud Mock et de locale documentées ici ne précisent pas d'exigence de forfait spécifique, il est donc honnête de vérifier la disponibilité actuelle dans votre propre compte plutôt que de se fier à un chiffre d'un article de blog. Vous pouvez Télécharger Apidog et essayer le processus de bout en bout pour voir exactement ce que votre espace de travail comprend.
Automatiser le flux de travail avec l'Apidog CLI
La simulation dans Apidog est une capacité graphique (GUI) et cloud. Les réponses de simulation sont générées automatiquement à partir de votre schéma de point de terminaison, et servies par le moteur hébergé d'Apidog, et non par quelque chose que vous exécutez dans un terminal. Le cadre honnête est donc le suivant : l'Apidog CLI ne démarre ni ne sert un serveur de simulation. Ce qu'il fait, c'est maintenir la précision des entrées de votre simulation.
Le CLI et les agents de codage IA comme Cursor ou Claude Code peuvent créer et mettre à jour les points de terminaison et les schémas de votre projet. Parce que la simulation cloud lit ces schémas pour générer des données, maintenir la spécification à jour garantit la fidélité de la sortie de la simulation à mesure que l'API évolue. Lorsque vous utilisez un outil agentique pour ajouter un champ, la simulation le reflète sans édition manuelle.
Ensuite, une fois que la simulation a débloqué le travail frontend et que le vrai backend est déployé, les scénarios de test du même projet s'exécutent sans interface graphique contre celui-ci. La commande d'exécution du CLI valide le backend en direct par rapport au même contrat que la simulation a décrit :
apidog run -t <scenario_id> -e <env_id> -r cli
Cette seule commande exécute un scénario de test enregistré contre un environnement et rapporte les résultats, de sorte que la simulation qui a débloqué l'interface utilisateur et les tests qui vérifient le backend remontent tous deux à une source unique de vérité. Ouvrez votre scénario dans Apidog et copiez la commande générée avec l'ID de scénario `-t` et l'ID d'environnement `-e` déjà renseignés, plutôt que d'assembler les drapeaux manuellement. L'intégration de cela dans un pipeline est couverte dans le guide sur l'exécution d'Apidog dans un pipeline CI/CD.
FAQ
L'URL de simulation cloud continue-t-elle de fonctionner lorsque je ferme Apidog ?
Oui, c'est tout l'intérêt de Cloud Mock. Contrairement à une simulation locale, qui cesse de répondre lorsque la machine hôte s'arrête, la simulation cloud est servie à partir de l'infrastructure d'Apidog et reste disponible 24h/24 et 7j/7. Vos coéquipiers peuvent l'utiliser que votre ordinateur soit allumé ou non.
Puis-je utiliser l'URL de simulation cloud directement dans un navigateur ?
Pour les requêtes GET, oui. Collez l'URL complète, y compris le paramètre de requête `apidogToken`, dans votre barre d'adresse et vous verrez la réponse JSON. Pour d'autres méthodes ou pour garder le jeton hors de l'historique de votre URL, appelez-le avec un outil comme curl ou votre client frontend et transmettez le jeton en tant qu'en-tête.
Qu'arrive-t-il aux requêtes qui n'incluent pas le jeton ?
Si vous avez défini la permission d'accès sur l'Authentification par jeton, toute requête sans `apidogToken` valide est rejetée. Fournissez-le comme paramètre de chaîne de requête, en-tête de requête ou paramètre de corps dans une requête de formulaire. Si vous activez l'authentification par jeton après avoir partagé une URL simple, informez vos consommateurs afin qu'ils puissent ajouter le jeton avant que leurs appels ne commencent à échouer.
Comment obtenir des données de simulation correspondant à un pays spécifique ?
Définissez la locale de votre projet dans les Paramètres de base, ou surchargez-la pour l'ensemble du projet sous Paramètres des fonctionnalités > Paramètres de simulation, ou surchargez un seul champ avec le paramètre `locale` dans l'expression de simulation, tel que `{{$person.fullName(locale='ja')}}`. Le niveau du champ l'emporte sur le niveau du projet, qui l'emporte sur la valeur par défaut des Paramètres de base. La présentation du smart mock montre comment la génération sensible au schéma s'y intègre.
Dois-je utiliser Cloud Mock ou un outil de simulation sans interface graphique ?
Cloud Mock convient aux équipes qui souhaitent un point de terminaison hébergé et sans maintenance, lié à la conception de leur API. Si vous avez besoin de simulations intégrées dans une compilation automatisée sans aucune interface graphique, l'aperçu des outils de simulation sans interface graphique compare les options et leur pertinence. La spécification OpenAPI Initiative est la base de la plupart de ces outils, donc une spécification propre est rentable quelle que soit la voie que vous choisissez.
En résumé
Une simulation qui ne vit que sur votre ordinateur portable ne débloque qu'une seule personne. Cloud Mock la transforme en une URL publique `mock.apidog.com` sur laquelle toute votre équipe peut se baser, avec une authentification par jeton lorsque vous devez la protéger et des contrôles de locale lorsque vos données doivent paraître réelles pour une région spécifique. Concevez le point de terminaison, activez l'interrupteur, partagez le lien, et le frontend cesse d'attendre le backend. Téléchargez Apidog pour configurer votre première simulation cloud partageable, gratuitement et sans carte de crédit requise.
bouton