Une API simulée (mock API) est une fausse API qui se comporte comme une vraie. Elle accepte les mêmes requêtes, renvoie des réponses de la même forme et est accessible via une URL que vous pouvez appeler, mais derrière cette URL, il n'y a pas de véritable base de données, pas de logique métier et pas de service réel. La réponse est quelque chose que vous avez défini à l'avance.
Cela semble trivial, et l'idée l'est. La valeur réside dans ce que cela vous permet de faire : construire et tester une interface avant que la chose derrière elle n'existe, ou lorsque la chose réelle est trop lente, trop coûteuse ou trop peu fiable pour être appelée. Cette explication définit précisément le terme, distingue une simulation des concepts avec lesquels elle est confondue, et expose la distinction statique/dynamique qui détermine le comportement d'une simulation.
Qu'est-ce qu'une API simulée concrètement ?
En simplifiant, une API simulée est une carte requête-réponse. Une requête arrive. La simulation la confronte aux règles que vous avez définies, choisit une réponse et la renvoie. Il n'y a pas de calcul intermédiaire à moins que vous ne le demandiez.
Une simulation se compose de trois parties. Il y a l'interface : les routes, les méthodes et les paramètres qu'elle accepte, qui doivent correspondre exactement à l'API réelle. Il y a la définition de la réponse : les corps, les codes de statut et les en-têtes qu'elle renvoie. Et il y a la logique de correspondance : comment la simulation décide quelle réponse une requête donnée obtient, allant d'une simple correspondance de chemin à des règles qui se ramifient sur des paramètres de requête ou des en-têtes.
Parce que l'interface correspond à l'API réelle, le code qui appelle la simulation ne sait pas qu'elle est fausse. Échangez l'URL de base et le même client communique avec le service réel. Cette interchangeabilité est le but principal. Pour une démonstration pratique de la construction d'une telle API, consultez ce guide sur la simulation d'une API pour les tests.
Il est utile d'être précis sur ce qu'une API simulée n'est pas. Ce n'est pas un cache, car un cache stocke de vraies réponses et une simulation les invente. Ce n'est pas un bac à sable (sandbox), car un bac à sable de fournisseur exécute une logique réelle et simplifiée, alors qu'une simulation n'exécute aucune logique. Et ce n'est pas un environnement de staging, car le staging est un déploiement complet du système réel. Une simulation est plus légère que les trois : c'est juste la porte d'entrée d'une API avec des réponses prédéfinies derrière elle, et rien d'autre.
Simulation versus bouchon (stub)
Les gens utilisent "simulation" et "bouchon" de manière interchangeable, mais en test, ils signifient des choses différentes.
Un bouchon est l'idée la plus simple. Il renvoie une réponse pré-enregistrée à un appel et rien de plus. Demandez-lui un utilisateur, il renvoie un utilisateur fixe. Un bouchon n'a pas d'opinion sur la manière dont il a été appelé.
Une simulation, au sens strict du test, vérifie également l'interaction. Elle peut affirmer qu'elle a été appelée, combien de fois et avec quels arguments. Une simulation peut faire échouer votre test parce que l'appel était incorrect, et pas seulement fournir une valeur.
Dans le travail quotidien avec les API, la frontière est floue, et "API simulée" couvre généralement les deux. Le point clé à retenir : un bouchon répond, une simulation répond et observe. Lorsque votre test ne se soucie que des données que votre code reçoit, une réponse de type bouchon est suffisante. S'il se soucie de savoir si votre code a effectué le bon appel de la bonne manière, vous voulez la vérification qu'une vraie simulation ajoute. Pour un vocabulaire plus large, consultez la différence entre validation et vérification.
Deux autres termes sont proches. Un "fake" est une implémentation fonctionnelle mais simplifiée, comme une base de données en mémoire utilisée à la place d'une vraie ; elle a de la logique, juste moins. Un "spy" enveloppe un objet réel et enregistre comment il a été appelé sans modifier son comportement. Une API simulée, telle que le terme est utilisé dans le développement d'API, est la plus proche d'un bouchon avec vérification optionnelle, servie via HTTP à une URL réelle. Vous n'avez pas besoin de surveiller le vocabulaire, mais connaître le spectre vous aide à lire la documentation de test sans vous perdre.
API simulée versus serveur réel
Un serveur réel et un serveur simulé peuvent se trouver à la même URL et renvoyer le même JSON ; la différence réside donc dans ce qui se passe derrière le point d'accès.
| API simulée | Serveur réel | |
|---|---|---|
| Derrière le point d'accès | Réponses prédéfinies | Logique active et base de données |
| Source de la réponse | Règles que vous avez écrites | Calculée par requête |
| Données | Fixes ou générées | Réelles, persistantes |
| Effets secondaires | Aucun | Écritures, paiements, e-mails |
| Vitesse | Rapide et constante | Varie avec la charge |
| Exactitude | Correspond à ce que vous avez défini | Correspond au comportement réel |
Un serveur réel vous dit la vérité : il exécute le code réel et prouve que le système fonctionne. Il est également lent, gère l'état et peut avoir de réels effets secondaires, de sorte qu'un test le concernant peut débiter une carte ou envoyer un e-mail.
Un serveur simulé ne vous dit que ce que vous lui avez dit. Il est rapide, sans effets secondaires et parfaitement prévisible, ce qui le rend idéal pour le développement et la plupart des tests. Mais une simulation peut être erronée et ne jamais le savoir, car elle n'exécute pas la logique réelle. C'est pourquoi vous conservez certains tests sur le serveur réel. Le compromis est abordé en profondeur dans serveur simulé versus serveur réel.
Simulations statiques et dynamiques
Une simulation renvoie sa réponse de l'une des deux manières suivantes, et le choix façonne la façon dont la simulation est perçue à l'usage.
Une simulation statique renvoie une charge utile fixe. Vous écrivez le JSON exact une fois, et chaque requête correspondante reçoit le même corps. Les simulations statiques sont prévisibles, ce qui les rend faciles à vérifier. Leur faiblesse est le réalisme : une seule charge utile codée en dur ne révélera pas un bogue dans un code qui échoue sur de longues chaînes, des tableaux vides ou des null inattendus.
Une simulation dynamique génère la réponse par requête. Au lieu d'un "id": "user_1001" fixe, elle produit un nouveau UUID à chaque appel. Au lieu d'un seul nom, elle renvoie un nom réaliste différent à chaque fois. Les simulations dynamiques pilotent généralement cela avec une grammaire de génération de données telle que Faker.js, de sorte qu'un champ nommé email produit un e-mail et created_at une date. Elles sont plus réalistes et meilleures pour exposer les cas limites, au prix d'être plus difficiles à vérifier précisément.
La plupart des équipes utilisent les deux. Des simulations statiques pour les tests unitaires axés sur les assertions où vous avez besoin d'une valeur connue. Des simulations dynamiques pour le développement, les démos et la couverture de type "fuzz" où la variété compte plus qu'une réponse fixe.
Une simulation dynamique peut également être conditionnelle, ce qui est un pas au-delà de la simple génération. Une simulation conditionnelle se ramifie sur la requête : une requête pour /orders/404 renvoie un 404, une requête avec un jeton incorrect renvoie un 401, et tout le reste renvoie un 200 normal. Un point de terminaison simulé couvre alors le scénario nominal et plusieurs chemins d'erreur à la fois. C'est ce qui rend une simulation véritablement utile pour les tests, car elle peut reproduire les réponses d'erreur qu'un serveur réel sain ne produira pas à la demande.
Où une API simulée s'intègre-t-elle dans le développement ?
Une API simulée est utile à trois moments. Au début, elle permet aux équipes frontend et backend de s'entendre sur un contrat et de construire en parallèle, de sorte qu'aucune n'attende l'autre. Pendant les tests, elle isole votre code des instabilités réseau et vous permet de déclencher des réponses d'erreur qu'un serveur réel ne produira pas à la demande. Et pour les démos et les prototypes, elle fournit des données contrôlées et prévisibles sans dépendance réelle susceptible de tomber en panne en plein exposé. Ces scénarios sont explorés plus en détail dans ce guide sur les cas d'utilisation de la simulation d'API.
Le risque récurrent est la dérive. Une simulation est un instantané d'une interface, et les interfaces changent. Lorsque l'API réelle ajoute un champ ou en renomme un, une simulation déconnectée continue de servir l'ancienne forme et vos tests réussissent par rapport à un contrat qui n'existe plus.
La solution est de traiter la simulation comme dérivée, et non comme écrite manuellement. Générez-la à partir du même schéma que celui publié par l'API réelle, de sorte qu'un changement de contrat régénère la simulation. Une simulation que vous avez tapée à la main est une copie qui commence immédiatement à vieillir ; une simulation générée à partir de la spécification est toujours un instantané actuel. La différence n'apparaît pas le premier jour, mais elle décide si la simulation est toujours fiable six mois plus tard. Apidog fonctionne de cette manière : vous concevez l'API une fois, et le point de terminaison simulé est généré à partir de cette conception avec des données réalistes déduites des noms de champs. La simulation, la documentation et les tests de contrat d'API lisent tous à partir d'une source unique, de sorte qu'ils restent synchronisés. Pour voir le flux complet de la conception à la simulation, Téléchargez Apidog.
Foire aux questions
Qu'est-ce qu'une API simulée en termes simples ?
Une API simulée est une fausse API qui imite une vraie. Elle expose les mêmes routes et renvoie des réponses de la même forme, mais il n'y a pas de logique réelle ni de base de données derrière elle. Les réponses sont prédéfinies, ce qui vous permet de construire et de tester l'interface avant que le service réel n'existe.
Quelle est la différence entre une simulation (mock) et un bouchon (stub) ?
Un bouchon renvoie une réponse pré-enregistrée et rien d'autre. Une simulation, au sens strict du test, vérifie également l'interaction, de sorte qu'elle peut vérifier qu'elle a été appelée le bon nombre de fois avec les bons arguments. Un bouchon répond ; une simulation répond et observe.
En quoi une API simulée est-elle différente d'un serveur réel ?
Une simulation renvoie des réponses prédéfinies sans aucun calcul réel, elle est donc rapide, prévisible et sans effets secondaires. Un serveur réel exécute une logique réelle sur une base de données réelle, il est donc plus lent et gère l'état, mais prouve que le système fonctionne vraiment. Utilisez une simulation pour le développement, et le serveur réel pour les tests de contrat et de bout en bout.
Dois-je utiliser une simulation statique ou dynamique ?
Utilisez une simulation statique lorsque vous avez besoin d'une valeur prévisible à vérifier, ce qui convient aux tests unitaires. Utilisez une simulation dynamique lorsque vous voulez des données réalistes et variées qui détectent les cas limites, ce qui convient au développement et aux démos. De nombreuses équipes utilisent les deux.
Comment éviter qu'une API simulée ne devienne inexacte ?
Générez la simulation à partir du même schéma que celui publié par l'API réelle, plutôt que de l'écrire à la main. Lorsque le contrat change, la simulation est régénérée. Le fait de la soutenir par des tests de contrat planifiés par rapport à l'API réelle permet de détecter rapidement toute dérive restante.