Bruno est un client API léger, natif de Git et open-source, et cette conception le rend rapide et facile à versionner. Mais cela laisse une lacune que les équipes rencontrent rapidement : il n'y a aucun moyen de simuler un point de terminaison qui n'existe pas encore. Si vous avez cherché une alternative de serveur de simulation Bruno, ce guide explique pourquoi cette lacune existe, les solutions de contournement utilisées par les gens, et comment générer un serveur de simulation directement à partir de votre spécification OpenAPI.
Réponse courte d'emblée : Bruno n'a pas de serveur de simulation intégré. Vous pouvez envoyer des requêtes et écrire des tests, mais vous ne pouvez pas créer un faux point de terminaison qui renvoie des exemples de réponses. Pour simuler, vous devez utiliser un outil externe ou coder un serveur vous-même.
Pourquoi avez-vous besoin d'un serveur de simulation ?
Un serveur de simulation renvoie des réponses réalistes pour des points de terminaison qui ne sont pas construits, ne sont pas stables ou sont difficiles à déclencher à la demande. Cela débloque plusieurs choses :
- Développement parallèle. Les équipes front-end et mobile construisent en fonction du contrat pendant que le backend est toujours en cours. Personne n'attend.
- Tests des chemins d'erreur. Les vraies API vous renvoient rarement un 429 ou un 503 quand vous en avez besoin. Une simulation renvoie n'importe quel statut, en-tête ou corps malformé sur commande.
- Démos et prototypes. Présentez un flux de travail fonctionnel sans backend réel, base de données ou identifiants.
- CI stable. Les tests qui interrogent une simulation ne tombent pas en panne parce qu'un serveur de staging est hors service ou soumis à des limites de débit.
Voici les scénarios d'échec qu'une simulation vous aide à tester délibérément, au lieu d'attendre qu'ils se produisent en production :
| Scénario | Ce que la simulation renvoie | Pourquoi c'est difficile autrement |
|---|---|---|
| Limite de débit atteinte | 429 + en-tête Retry-After |
Le backend limite rarement le débit à la demande |
| Panne de serveur | 500 / 503 |
Impossible de faire tomber le staging juste pour tester |
| Réponse lente | Corps retardé | Difficile de reproduire une latence réelle |
| Jeu de résultats vide | 200 avec [] |
Dépend de l'état spécifique des données |
| Charge utile mal formée | Corps manquant un champ requis | La validation du backend l'empêche généralement |
Bruno a-t-il un serveur de simulation ?
Non. Bruno se concentre sur l'envoi de requêtes, l'organisation des collections sous forme de fichiers plats et l'exécution d'assertions. Il n'y a pas de serveur de simulation natif, et aucune option ne transforme une requête enregistrée en un stub actif. C'est un choix délibéré de portée, pas une omission, mais cela signifie que la simulation se fait en dehors de l'outil.
En pratique, les utilisateurs de Bruno comblent cette lacune de deux manières :
- Outils de simulation externes. Mettre en place un service distinct comme Mockoon, WireMock, Prism ou json-server, y définir les réponses, puis pointer Bruno vers cette URL. Deux outils, deux sources de vérité.
- Serveurs faits maison. Écrire une petite application Express, Flask ou FastAPI qui renvoie du JSON pré-enregistré. Rapide pour un point de terminaison, fastidieux à maintenir pour une API croissante.
Les deux fonctionnent. Les deux ajoutent des éléments mobiles qui vivent en dehors de votre collection.
Le coût de la simulation "bolt-on"
L'ajout d'une couche de simulation séparée à Bruno est réalisable, mais le coût se manifeste avec le temps :
- Dérive. Votre spécification, vos requêtes Bruno et vos définitions de simulation vivent à trois endroits. Changez un point de terminaison et vous mettez à jour les trois, ou l'un d'eux devient silencieusement obsolète.
- Coût d'installation. Chaque nouveau membre de l'équipe installe et configure l'outil de simulation avant de pouvoir exécuter quoi que ce soit localement.
- Écriture manuelle des réponses. Les serveurs faits maison signifient écrire manuellement des exemples de charges utiles pour chaque champ et chaque code de statut.
- Pas de données réalistes. Les stubs statiques renvoient le même
"name": "string"à chaque fois, ce qui cache des bugs qui n'apparaissent qu'avec des entrées variées.
Rien de tout cela n'est fatal. Mais c'est une friction qui s'aggrave à mesure que l'API se développe. Pour un aperçu plus complet de la façon dont ces lacunes s'accumulent, consultez notre analyse de la plateforme API tout-en-un alternative à Bruno.
Générez plutôt un serveur de simulation à partir de votre spécification OpenAPI
La voie la plus propre consiste à dériver la simulation du contrat que vous maintenez déjà. Apidog le fait : importez ou écrivez une spécification OpenAPI, et il génère un serveur de simulation fonctionnel à partir des mêmes définitions que celles que vous utilisez pour la conception, les tests et la documentation. Une seule source de vérité, pas trois.
Plusieurs choses distinguent cette approche des outils "bolt-on" :
- Simulation intelligente à partir de la spécification. Apidog lit les noms et les types de champs et renvoie des données plausibles, de sorte qu'un champ
emailressemble à un e-mail et un champcreated_atressemble à une date, sans règles à écrire. - Réponses dynamiques. Les réponses sont générées à partir de votre schéma à chaque requête, vous obtenez donc des données variées au lieu d'un exemple figé. Vous pouvez ajouter des règles conditionnelles lorsque vous avez besoin d'un cas spécifique.
- Configuration sans code. Vous n'écrivez ni n'hébergez un serveur séparé. Définissez le point de terminaison dans la spécification et l'URL de simulation est prête.
- Synchronisation constante. Mettez à jour la spécification et la simulation est mise à jour avec elle, car elles partagent une seule définition.
Parce que la simulation, la bibliothèque de requêtes et la documentation proviennent du même projet, il n'y a pas de troisième endroit à aligner. Si votre flux de travail est centré sur Git, la spécification reste différentiable et révisable, ce qui s'accorde bien avec un flux de travail API natif de Git. Pour en savoir plus sur les avantages de la simulation, consultez les cas d'utilisation de la simulation d'API.
Guide rapide : de la spécification à l'URL de simulation
Voici la version courte de la mise en place d'une simulation à partir d'une spécification existante :
- Importez votre spécification. Importez votre fichier OpenAPI (ou Swagger), ou pointez Apidog vers l'URL de la spécification. Les points de terminaison et les schémas existants sont importés tels quels.
- Ouvrez un point de terminaison. Chaque point de terminaison importé a déjà son schéma, donc la simulation a tout ce dont elle a besoin.
- Récupérez l'URL de simulation. Apidog expose automatiquement un point de terminaison de simulation local et cloud. Aucun serveur à déployer.
- Envoyez une requête. Interrogez l'URL de simulation et vous obtiendrez du JSON conforme au schéma, généré à partir de la spécification.
- Ajustez les réponses (facultatif). Ajoutez des règles pour des codes de statut spécifiques ou des cas limites, comme ce
429, lorsque vous avez besoin de tester un chemin particulier.
Vous pointez votre front-end, votre build mobile ou votre suite de tests vers l'URL de simulation et continuez à avancer pendant que le backend se rattrape.
Quand les solutions de contournement sont suffisantes
Pour être juste, vous n'avez pas toujours besoin d'une simulation basée sur une spécification. Tenez-vous-en à Bruno et à un outil externe léger lorsque :
- Vous n'avez besoin de simuler qu'un ou deux points de terminaison pour un test local rapide.
- Votre équipe est satisfaite de maintenir les collections de Bruno basées sur des fichiers et ne veut pas changer d'outils.
- Un stub statique suffit car vous ne testez pas de données variées ou de nombreux chemins d'erreur.
- Vous utilisez déjà Mockoon, WireMock ou Prism et la source de vérité supplémentaire ne vous ralentit pas.
Le compromis est réel : la voie légère maintient la simplicité de Bruno mais vous oblige à maintenir les simulations séparément. La voie basée sur la spécification élimine cette dérive au prix de l'adoption d'une plateforme plus large. Choisissez en fonction de la croissance de votre API.
FAQ
Bruno a-t-il un serveur de simulation intégré ?
Non. Bruno est un client API pour l'envoi de requêtes et l'exécution de tests. Il n'a pas de serveur de simulation natif, donc pour simuler des points de terminaison, vous utilisez un outil externe ou écrivez votre propre serveur de stub et y pointez Bruno.
Quelle est la manière la plus simple d'ajouter la simulation à un flux de travail de style Bruno ?
Générez la simulation à partir de votre spécification OpenAPI au lieu de la définir séparément. Des outils comme Apidog lisent la spécification et produisent une URL de simulation prête à l'emploi, vous permettant de conserver une seule source de vérité pour la conception, la simulation, les tests et la documentation, plutôt que de maintenir les définitions de simulation à un second endroit.
Puis-je continuer à utiliser Bruno et simplement ajouter un serveur de simulation à côté ?
Oui. Exécutez un outil de simulation externe tel que Mockoon, WireMock ou Prism, définissez les réponses là-bas, et pointez Bruno vers cette URL. Cela fonctionne, mais votre spécification, vos requêtes et vos données de simulation vivent à des endroits séparés et peuvent dériver, ce qui est la principale raison pour laquelle les équipes se consolident.
Si la maintenance d'une couche de simulation séparée a commencé à coûter plus qu'elle ne rapporte, il vaut la peine d'essayer une simulation basée sur une spécification. Importez votre fichier OpenAPI dans Apidog et vous aurez une URL de simulation fonctionnelle en quelques minutes, sans serveur supplémentaire à héberger.