DEV Community

Cover image for Comment héberger un serveur de mock cloud partageable avec Apidog
Antoine Laurent
Antoine Laurent

Posted on • Originally published at apidog.com

Comment héberger un serveur de mock cloud partageable avec Apidog

Votre équipe frontend est bloquée : le design est validé, les écrans avancent, mais l’API backend n’est pas encore disponible. Une simulation locale peut dépanner, mais elle disparaît dès que la machine qui l’héberge est arrêtée. Pour débloquer durablement le frontend, la QA et les partenaires, utilisez une URL de simulation accessible en continu.

Essayez Apidog dès aujourd’hui

C’est le rôle de Cloud Mock d’Apidog : générer une URL publique sur mock.apidog.com, disponible indépendamment de votre poste de travail. Les équipes frontend peuvent intégrer l’API avant le déploiement du backend, tandis que la QA peut préparer ses scénarios de test. Pour le contexte, consultez ce qu’est une simulation d’API et quand l’utiliser, ainsi que la référence MDN du modèle requête/réponse HTTP.

Qu’est-ce que Cloud Mock ?

Apidog génère une simulation pour les endpoints définis dans votre projet. Par défaut, cette simulation est locale : elle répond tant que votre instance Apidog et votre machine sont actives.

Cette approche convient au débogage individuel, mais elle ne convient pas à une équipe distribuée. Si un collègue, un testeur ou un partenaire dépend de votre URL locale, son accès disparaît lorsque vous fermez votre ordinateur.

Cloud Mock fournit à la place un endpoint hébergé, disponible 24h/24 et 7j/7. Le flux de travail devient simple :

  1. Concevez le contrat API.
  2. Activez Cloud Mock.
  3. Partagez une URL unique.
  4. Laissez le frontend, la QA et les intégrateurs travailler contre la même réponse simulée.

Pour les équipes réparties dans plusieurs fuseaux horaires, consultez ces modèles de partage de serveurs de simulation et d’environnements.

Activer Cloud Mock et récupérer une URL publique

Prenons un endpoint réaliste :

GET /users
Enter fullscreen mode Exit fullscreen mode

Il doit renvoyer une liste de clients. Voici comment le rendre accessible à toute l’équipe.

Étape 1 : activer Cloud Mock

Dans votre projet Apidog, ouvrez :

Paramètres du projet > Paramètres des fonctionnalités > Paramètres de simulation

Activez Cloud Mock.

Cette opération est réalisée une seule fois par projet. Une fois activée, chaque endpoint dispose d’une URL locale et d’une URL Cloud Mock.

Activation de Cloud Mock

Étape 2 : copier l’URL Cloud Mock

Ouvrez l’endpoint GET /users, puis allez dans l’onglet Mock. Copiez l’URL Cloud Mock affichée par Apidog.

Exemple :

https://mock.apidog.com/m1/2689726-0-default/users?apidogToken=GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi
Enter fullscreen mode Exit fullscreen mode

Le chemin suit généralement cette structure :

mock.apidog.com/m1/<projectId>-<num>-<env>/<path>
Enter fullscreen mode Exit fullscreen mode

Ne construisez pas cette URL manuellement : copiez toujours celle générée dans Apidog. Elle est la source de vérité pour votre projet et votre environnement.

Étape 3 : tester la réponse dans Apidog

Dans l’onglet Mock, envoyez une requête de test à l’URL Cloud Mock. Vérifiez notamment :

  • le code de statut HTTP ;
  • la structure JSON ;
  • les champs requis ;
  • les valeurs générées ;
  • les cas d’erreur éventuels.

Une réponse simulée pour GET /users peut ressembler à 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"
  }
]
Enter fullscreen mode Exit fullscreen mode

Apidog génère ces valeurs à partir des noms et des types définis dans votre schéma. Le frontend travaille donc avec des données plus proches des réponses de production qu’avec des valeurs génériques telles que "string".

Étape 4 : appeler l’endpoint depuis le frontend

Pour une requête GET, vous pouvez ouvrir l’URL dans un navigateur afin de vérifier rapidement le JSON retourné.

Dans un terminal :

curl "https://mock.apidog.com/m1/2689726-0-default/users?apidogToken=GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi"
Enter fullscreen mode Exit fullscreen mode

Dans votre application, utilisez l’URL comme n’importe quel endpoint REST :

const response = await fetch(
  "https://mock.apidog.com/m1/2689726-0-default/users?apidogToken=GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi"
);

const users = await response.json();
Enter fullscreen mode Exit fullscreen mode

Vous avez maintenant un contrat partageable : le frontend peut avancer sans attendre le backend.

Protéger la simulation avec un jeton

Une URL publique est pratique, mais une simulation peut représenter une fonctionnalité non publiée ou une intégration partenaire. Dans ce cas, activez l’authentification par jeton.

Allez dans :

Paramètres du projet > Paramètres des fonctionnalités > Paramètres de simulation

Définissez ensuite la permission d’accès sur Authentification par jeton.

Chaque requête devra alors inclure un apidogToken valide.

Option 1 : transmettre le jeton dans l’URL 

curl "https://mock.apidog.com/m1/2689726-0-default/users?apidogToken=GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi"
Enter fullscreen mode Exit fullscreen mode

Cette option est utile pour tester rapidement un endpoint dans un navigateur ou avec curl.

Option 2 : transmettre le jeton dans un en-tête

Pour les applications frontend, préférez généralement un en-tête HTTP. Cela évite de placer le jeton dans l’URL et dans les journaux qui enregistrent les URL complètes.

curl "https://mock.apidog.com/m1/2689726-0-default/users" \
  -H "apidogToken: GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi"
Enter fullscreen mode Exit fullscreen mode

Avec fetch :

const response = await fetch(
  "https://mock.apidog.com/m1/2689726-0-default/users",
  {
    headers: {
      apidogToken: "GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi"
    }
  }
);

const users = await response.json();
Enter fullscreen mode Exit fullscreen mode

Vous pouvez également transmettre apidogToken dans le corps d’une requête form-data ou x-www-form-urlencoded.

Si vous activez l’authentification par jeton après avoir partagé une URL non protégée, prévenez les consommateurs de l’API. Sans jeton valide, leurs requêtes seront rejetées.

Générer des données réalistes avec les locales

Une simulation utile ne renvoie pas seulement la bonne structure : elle doit aussi produire des données qui révèlent les problèmes réels de l’interface.

Par exemple, des noms, adresses et numéros de téléphone réalistes permettent de détecter :

  • les débordements de texte ;
  • les problèmes de largeur de colonnes ;
  • les erreurs de formatage ;
  • les hypothèses incorrectes sur les alphabets ou les adresses ;
  • les défauts d’internationalisation.

Apidog s’appuie sur Faker.js pour générer ces valeurs.

Définir la locale par défaut du projet

Par défaut, Faker utilise la langue configurée dans :

Paramètres du projet > Paramètres de base

Si votre projet est configuré en français, les données simulées utiliseront cette locale par défaut.

Surcharger la locale pour l’ensemble du projet

Pour tester une autre région sans modifier la langue globale du projet :

  1. Ouvrez Paramètres du projet > Paramètres des fonctionnalités > Paramètres de simulation.
  2. Sélectionnez une locale Faker.
  3. Relancez vos requêtes simulées.

Par exemple, définissez une locale japonaise pour tester les scripts non latins, les noms japonais et les formats d’adresse associés.

Pour comprendre comment Apidog génère les réponses à partir de votre schéma, consultez le guide sur le smart mock d’Apidog.

Surcharger la locale pour un seul champ

Vous pouvez définir une locale directement dans une expression de simulation :

{{$person.fullName(locale='ja')}}
Enter fullscreen mode Exit fullscreen mode

Ce champ peut alors générer une valeur telle que :

田中 太郎
Enter fullscreen mode Exit fullscreen mode

Les autres champs continuent d’utiliser la locale du projet.

L’ordre de priorité est le suivant :

  1. locale définie au niveau du champ ;
  2. locale définie dans les paramètres de simulation du projet ;
  3. langue configurée dans les paramètres de base.

Utilisez les surcharges par champ lorsque votre réponse doit représenter une cohorte internationale mixte.

La documentation montre ja comme exemple, mais vérifiez le code de locale nécessaire pour votre cas d’usage dans la documentation Apidog et dans la référence de localisation Faker.js.

Configurer également le fuseau horaire

Pour les champs temporels, configurez le fuseau horaire dans :

Paramètres du projet > Paramètres des fonctionnalités > Paramètres de simulation

Vous pouvez également le surcharger au niveau du champ avec le paramètre timeZone dans une expression de simulation.

Cette configuration est importante si votre frontend affiche des champs comme :

{
  "createdAt": "2026-07-15T09:30:00Z"
}
Enter fullscreen mode Exit fullscreen mode

Associer locale et fuseau horaire permet de tester une interface pour une région donnée sans modifier le schéma de l’endpoint. Pour d’autres scénarios, consultez les cas d’utilisation pratiques de la simulation d’API.

Cloud Mock ou simulation auto-hébergée ?

Cloud Mock est l’option hébergée d’Apidog. Elle convient lorsque vous voulez une URL accessible en continu sans administrer d’infrastructure.

Choisissez plutôt une simulation auto-hébergée si votre organisation impose :

  • des règles de résidence des données ;
  • un trafic de test limité à votre réseau ;
  • une politique qui interdit le transit via le cloud d’un fournisseur.

Le compromis est direct :

Option Avantage principal Contrepartie
Cloud Mock Aucune infrastructure à maintenir, disponibilité continue Le service est hébergé par Apidog
Auto-hébergement Contrôle de l’infrastructure et du trafic Vous exploitez vous-même le service

Pour ce second cas, consultez le guide pour auto-héberger le serveur de simulation Apidog. Vous pouvez aussi comparer les solutions avec cette comparaison des outils de simulation d’API en ligne.

Les fonctionnalités Cloud Mock et de locale décrites ici ne précisent pas d’exigence de forfait particulière. Vérifiez donc leur disponibilité dans votre propre espace de travail. Vous pouvez télécharger Apidog et tester le flux complet.

Automatiser le contrat avec l’Apidog CLI

Cloud Mock est un service graphique et hébergé : l’Apidog CLI ne démarre pas de serveur de simulation dans votre terminal.

Son rôle est de maintenir à jour les entrées de la simulation : vos endpoints, vos schémas et vos scénarios de test.

Le principe est le suivant :

  1. Mettez à jour le contrat API dans Apidog.
  2. Cloud Mock génère ses réponses à partir de ce schéma.
  3. Le frontend consomme la simulation.
  4. Lorsque le backend est prêt, exécutez les scénarios de test contre l’environnement réel.

Par exemple :

apidog run -t <scenario_id> -e <env_id> -r cli
Enter fullscreen mode Exit fullscreen mode

Cette commande exécute un scénario enregistré contre un environnement donné et retourne les résultats dans le terminal.

Pour éviter les erreurs de paramètres, ouvrez le scénario dans Apidog et copiez la commande générée : les valeurs -t et -e seront déjà renseignées.

Vous obtenez ainsi une source de vérité unique :

  • le schéma alimente la simulation ;
  • le frontend intègre la simulation ;
  • les tests valident ensuite le backend réel contre le même contrat.

Pour l’intégrer dans votre pipeline, consultez le guide d’exécution d’Apidog dans un pipeline CI/CD.

FAQ

L’URL Cloud Mock fonctionne-t-elle lorsque je ferme Apidog ?

Oui. Cloud Mock est hébergé sur l’infrastructure d’Apidog et reste disponible 24h/24 et 7j/7. Contrairement à une simulation locale, elle ne dépend pas de votre machine.

Puis-je ouvrir l’URL Cloud Mock dans un navigateur ?

Oui, pour les requêtes GET. Collez l’URL complète, y compris apidogToken si nécessaire, dans la barre d’adresse.

Pour les autres méthodes HTTP ou pour éviter d’exposer le jeton dans l’historique du navigateur, utilisez curl, Postman ou votre client frontend avec un en-tête HTTP.

Que se passe-t-il si une requête ne contient pas de jeton ?

Si l’Authentification par jeton est activée, toute requête sans apidogToken valide est rejetée.

Vous pouvez transmettre le jeton dans :

  • la chaîne de requête ;
  • un en-tête HTTP ;
  • le corps d’une requête de formulaire.

Comment générer des données correspondant à un pays précis ?

Utilisez l’un de ces niveaux de configuration :

  1. la langue dans les Paramètres de base ;
  2. la locale globale dans les Paramètres de simulation ;
  3. le paramètre locale dans une expression de simulation.

Exemple :

{{$person.fullName(locale='ja')}}
Enter fullscreen mode Exit fullscreen mode

Le paramètre de champ est prioritaire sur celui du projet, lui-même prioritaire sur la langue par défaut. Consultez également la présentation du smart mock.

Dois-je utiliser Cloud Mock ou un outil sans interface graphique ?

Utilisez Cloud Mock si vous voulez un endpoint hébergé, partageable et relié à la conception de votre API.

Si vous avez besoin d’une simulation intégrée à une compilation automatisée sans interface graphique, consultez cette comparaison des outils de simulation sans interface graphique.

Dans les deux cas, une spécification propre reste essentielle. La spécification OpenAPI Initiative constitue la base de la plupart de ces outils.

En résumé

Une simulation locale débloque surtout son auteur. Cloud Mock transforme votre contrat API en une URL publique mock.apidog.com que le frontend, la QA et les partenaires peuvent utiliser immédiatement.

Mettez en place ce flux :

  1. Concevez l’endpoint et son schéma.
  2. Activez Cloud Mock.
  3. Testez la réponse générée.
  4. Protégez l’accès avec un jeton si nécessaire.
  5. Configurez locale et fuseau horaire pour des données réalistes.
  6. Partagez l’URL avec les consommateurs de l’API.
  7. Validez ensuite le backend réel avec les mêmes scénarios.

Le frontend n’a plus besoin d’attendre le backend. Téléchargez Apidog pour créer votre première simulation cloud partageable.

Top comments (0)