Lorsque vous construisez un frontend, déboguez un client ou apprenez une nouvelle bibliothèque HTTP, vous avez souvent besoin d'un point d'accès qui renvoie du JSON d'apparence réelle sans avoir à mettre en place un backend. Une API factice (dummy API) vous offre exactement cela : un service public, gratuit, toujours disponible que vous pouvez appeler dès maintenant. Ce guide répertorie les meilleures API factices publiques, vous montre comment les appeler et explique quand cesser d'emprunter les données de quelqu'un d'autre pour construire votre propre fausse API REST à la place. Si vous souhaitez une introduction plus approfondie au paysage des API publiques, le guide MDN sur l'utilisation de l'API Fetch se marie bien avec tout ce qui suit.
Qu'est-ce qu'une API factice en réalité ?
Une API factice est un service hébergé qui renvoie des données JSON préenregistrées et réalistes pour des types de ressources courants : utilisateurs, publications, produits, paniers, tâches (todos). Vous ne vous inscrivez pas, vous n'hébergez rien et vous ne vous souciez pas de casser les données de production. La plupart d'entre elles acceptent les opérations GET, POST, PUT, PATCH et DELETE, mais les opérations d'écriture sont généralement simulées. Le serveur renvoie votre charge utile avec un identifiant et prétend qu'elle a été enregistrée, alors que rien ne persiste réellement.
C'est la caractéristique clé à comprendre avant de vous y fier. Une API factice est parfaite pour le prototypage axé sur la lecture et pour prouver que votre code de requête fonctionne. Elle est mal adaptée dès que vous avez besoin d'un comportement avec état, de vos propres formes de données ou de conditions d'erreur personnalisées.
Les meilleures API factices et fausses gratuites pour les tests
Voici les API publiques à connaître. Toutes sont gratuites et ne nécessitent aucune configuration backend de votre part.
JSONPlaceholder
JSONPlaceholder est le classique. Il sert six ressources connexes : 100 publications, 500 commentaires, 100 albums, 5 000 photos, 200 tâches et 10 utilisateurs. Les relations sont réelles, donc une publication a des commentaires et un album a des photos, ce qui le rend utile pour tester les récupérations imbriquées.
curl https://jsonplaceholder.typicode.com/posts/1
Vous obtenez un seul objet de publication. Les requêtes d'écriture sont acceptées mais non enregistrées, donc un POST /posts renvoie un faux id: 101 à chaque fois.
DummyJSON
DummyJSON va plus loin. Il propose des produits, des paniers, des utilisateurs, des publications, des commentaires, des citations, des tâches et des recettes, ainsi qu'un flux d'authentification qui vous fournit un jeton. Si vous testez une interface utilisateur de panier d'achat ou un écran de connexion, c'est celui qu'il vous faut.
curl https://dummyjson.com/products/1
Le point d'accès d'authentification vous permet d'envoyer un nom d'utilisateur et un mot de passe par POST et de recevoir un JWT, ce qui est pratique pour s'exercer au stockage de jetons et aux requêtes authentifiées sans configurer un véritable fournisseur d'identité.
reqres.in
reqres.in se concentre sur le cycle de vie des requêtes et des réponses : lister les utilisateurs, utilisateur unique, enregistrer, se connecter, réponses différées. Il est conçu pour démontrer la pagination et les flux d'authentification. Une chose à savoir : le niveau gratuit attend désormais un en-tête de clé API. Envoyez x-api-key: reqres-free-v1 avec vos requêtes, sinon vous obtiendrez un 401.
curl https://reqres.in/api/users/2 -H "x-api-key: reqres-free-v1"
Où chacun s'insère
| API factice | Idéal pour | Flux d'authentification | Persistance d'écriture |
|---|---|---|---|
| JSONPlaceholder | Lectures imbriquées, données de type blog | Non | Simulée, non enregistrée |
| DummyJSON | E-commerce, paniers, connexion | Oui (jeton) | Simulée, non enregistrée |
| reqres.in | Pagination, démos d'enregistrement/connexion | En-tête de clé API | Simulée, non enregistrée |
Si vous souhaitez un catalogue d'options plus large au-delà de ces trois, le récapitulatif des API publiques pour les tests couvre des choix plus spécialisés, et la liste des API publiques gratuites pour les développeurs est utile lorsque vous avez besoin de données thématiques comme la météo ou la devise.
Comment appeler une API factice dans votre code
Appeler une API factice est la même chose que d'appeler n'importe quel point d'accès HTTP. Voici un exemple simple de fetch en JavaScript qui lit un utilisateur puis en publie un nouveau.
// Read
const res = await fetch('https://dummyjson.com/users/1');
const user = await res.json();
console.log(user.firstName);
// Write (echoed back, not persisted)
const created = await fetch('https://dummyjson.com/users/add', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ firstName: 'Ada', lastName: 'Lovelace' }),
});
console.log(await created.json()); // returns an object with a fake id
En Python avec requests, la forme est tout aussi courte.
import requests
r = requests.get("https://jsonplaceholder.typicode.com/todos/1")
print(r.json())
Insérez l'un de ces exemples dans un fichier de test et vous disposerez d'une intégration fonctionnelle sur laquelle vous appuyer. Si vous avez besoin de valeurs crédibles pour ces assertions, le guide sur la création de données de test d'API réalistes montre comment générer des noms, des e-mails et des horodatages qui ressemblent à du trafic de production plutôt qu'à test123.
Quand une API factice publique ne suffit plus
Les API factices publiques sont excellentes jusqu'à ce que vos besoins deviennent spécifiques. Vous rencontrerez un obstacle dans quelques situations courantes :
- Vos formes de données ne correspondent pas. Votre application s'attend à un champ
subscription_tieret à un objetbillingimbriqué. JSONPlaceholder vous donne despostset desalbums. Vous ne pouvez pas adapter leur schéma au vôtre. - Vous avez besoin d'un état. Un vrai panier se met à jour lorsque vous ajoutez un article. Les API factices oublient votre POST dès qu'il est renvoyé.
- Vous avez besoin de pannes contrôlées. Tester comment votre interface utilisateur gère un 429, un 200 lent ou un corps mal formé est difficile lorsque le service public se comporte toujours parfaitement.
- Vous construisez avant l'existence du backend. Les équipes frontend et backend commencent souvent en même temps. Vous avez besoin de points de terminaison qui correspondent au contrat convenu aujourd'hui, et non lorsque l'API sera livrée.
À ce moment-là, vous n'avez pas besoin d'une API empruntée. Vous avez besoin de votre propre fausse API qui renvoie vos formes, à la demande, avec les réponses que vous contrôlez. C'est une API simulée conçue pour les tests, et c'est là qu'Apidog intervient.
Comment construire votre propre fausse API avec Apidog
Apidog est une plateforme API qui combine la conception, les tests, le débogage et la simulation en un seul endroit. Sa simulation est pilotée par schéma, de sorte qu'elle lit la structure de votre point de terminaison et génère automatiquement des données factices réalistes à l'aide de règles Faker intégrées. Vous définissez la forme une fois, et chaque requête renvoie des valeurs fraîches et plausibles.
Voici la version courte du workflow.
- Créez ou importez un point de terminaison. Définissez une nouvelle API dans Apidog, ou importez un fichier OpenAPI ou Swagger existant. Apidog lit le schéma directement.
- Laissez le simulateur intelligent remplir les données. Pour un champ nommé
email, Apidog renvoie un e-mail. PourcreatedAt, il renvoie un horodatage. Pourprice, un nombre. Vous pouvez ajuster ces règles par champ, de sorte qu'un champcountryrenvoie de vrais noms de pays au lieu de chaînes aléatoires. - Accédez à l'URL du simulateur local. Apidog lance un serveur de simulation et vous donne une URL pour chaque point de terminaison. Appelez-la depuis votre frontend, vos tests ou curl, exactement comme une API factice publique, sauf que les réponses correspondent à votre contrat.
- Ajoutez des réponses conditionnelles et d'erreur. Configurez une simulation pour renvoyer un 500, un 404 ou une réponse différée en fonction de la requête. Vous pouvez maintenant tester les chemins d'échec que les services publics ne vous permettent jamais de reproduire.
Parce que le simulateur est généré à partir de votre spécification, il reste synchronisé à mesure que votre conception évolue. Changez un champ, et le simulateur le reflète. Si vous souhaitez une vue plus large de la génération de simulations directement à partir d'une spécification, la présentation sur la génération de données de simulation à partir de schémas OpenAPI approfondit l'aspect Faker.
API factice publique vs. votre propre simulateur Apidog
| Besoin | API factice publique | Simulateur Apidog |
|---|---|---|
| Données en lecture seule rapides | Excellent | Excellent |
| Vos formes de données exactes | Non | Oui |
| Réponses d'erreur et de délai personnalisées | Non | Oui |
| Correspond à votre contrat OpenAPI | Non | Oui |
| Temps de configuration | Zéro | Quelques minutes |
Aucun n'est strictement meilleur. Une API factice publique l'emporte lorsque vous avez juste besoin de n'importe quel JSON en cinq secondes. Votre propre simulateur Apidog l'emporte dès que la justesse par rapport à votre contrat réel est importante. La plupart des équipes utilisent les deux : les API publiques pour des expériences jetables, une simulation de projet pour tout ce qui est livré.
Foire aux questions
Une API factice est-elle la même chose qu'une API simulée ?
Elles se chevauchent mais ne sont pas identiques. Une API factice désigne généralement un service public partagé avec des exemples de données fixes, comme JSONPlaceholder. Une API simulée est une API que vous définissez et contrôlez, renvoyant vos propres formes et comportements. Une API factice est une variante de simulation que quelqu'un d'autre héberge déjà. Si vous souhaitez la distinction expliquée en détail, consultez l'article sur ce qu'est une API simulée.
Les fausses API gratuites sont-elles sûres à utiliser avec des données réelles ?
Non. N'envoyez jamais de données utilisateur réelles, de secrets ou de jetons à une API factice publique. Considérez tout ce que vous envoyez par POST comme étant enregistré et visible. Utilisez-les uniquement avec des valeurs de test jetables. Lorsque vous avez besoin de confidentialité ou de persistance, hébergez votre propre simulation à la place.
Les API factices enregistrent-elles les données que j'envoie ?
Presque jamais. JSONPlaceholder, DummyJSON et reqres.in acceptent tous les requêtes d'écriture et renvoient un résultat avec un identifiant généré, mais rien ne persiste. Actualisez la page et votre enregistrement "créé" a disparu. Si vous avez besoin d'un état qui perdure, vous avez besoin d'une simulation avec état ou d'un véritable backend.
Puis-je créer une fausse API sans écrire de code ?
Oui. Avec Apidog, vous définissez la forme du point de terminaison et laissez la simulation intelligente générer les données, aucun code serveur n'est requis. Vous pouvez également importer un fichier OpenAPI et obtenir des points de terminaison de simulation fonctionnels en quelques minutes.
En résumé
Les API factices publiques comme JSONPlaceholder, DummyJSON et reqres.in sont le moyen le plus rapide d'obtenir du JSON réaliste pour le prototypage et l'apprentissage. Elles ne coûtent rien et ne nécessitent aucune configuration. Dès que vous avez besoin de vos propres formes de données, d'un état réel ou de réponses d'erreur contrôlées, construisez une fausse API que vous possédez réellement.
Apidog vous permet de faire exactement cela : importez votre spécification, obtenez des données simulées pilotées par schéma et appelez vos propres points de terminaison en quelques minutes. Téléchargez Apidog et transformez votre prochain contrat API en une simulation fonctionnelle avant même qu'une ligne de code backend n'existe. Découvrez comment il s'intègre à votre flux de travail de test chez Apidog.