Vous construisez un frontend, mais le backend n'est pas prêt. Vous avez besoin d'une API REST qui renvoie du JSON réaliste dès maintenant, avec des fonctions GET, POST, PUT et DELETE opérationnelles, afin de pouvoir continuer à coder au lieu d'attendre.
C'est à cela que sert json-server. Pointez-le vers un simple fichier JSON et il met en place une API REST complète en quelques secondes, sans code backend requis. Son jumeau, JSONPlaceholder, va encore plus loin : une fausse API hébergée que vous pouvez appeler sans rien installer. Ce guide montre comment utiliser les deux, leurs limites, et quand passer à un mock conscient des schémas dans Apidog.
Pour une vue d'ensemble sur la simulation de points d'accès, consultez ce qu'est une API mock. Ici, nous nous concentrons sur les deux outils que les développeurs utilisent en premier.
Qu'est-ce que json-server ?
json-server est un outil npm open-source qui transforme un simple fichier JSON en une véritable API REST. Vous écrivez un fichier db.json décrivant vos ressources, exécutez une commande, et vous obtenez des routes CRUD standard adossées à ce fichier. Les requêtes d'écriture modifient réellement le fichier, de sorte que les données persistent entre les requêtes pendant votre session.
C'est le moyen le plus rapide d'obtenir une API fonctionnelle pour le prototypage, le développement frontend, les démonstrations et les tests, sans avoir à configurer une base de données ou à écrire du code serveur. Le projet est hébergé sur GitHub et est largement utilisé pour cette tâche.
Installer et exécuter json-server
Installez-le depuis npm :
npm install json-server
Créez un fichier db.json dans votre projet. Les clés de tableau de premier niveau deviennent des routes de collection ; les objets de premier niveau deviennent des routes de ressource unique :
{
"posts": [
{ "id": "1", "title": "First post", "views": 100 },
{ "id": "2", "title": "Second post", "views": 250 }
],
"comments": [
{ "id": "1", "text": "Nice work", "postId": "1" }
],
"profile": {
"name": "apidog"
}
}
Démarrez le serveur :
npx json-server db.json
Il s'exécute sur http://localhost:3000 par défaut. C'est tout ; vous avez maintenant une API en direct.
Note sur les versions : json-server v1 a abandonné l'ancien drapeau--watch, doncnpx json-server db.jsonest la commande actuelle. Si vous utilisez l'ancienne ligne 0.x, vous verrez toujoursjson-server --watch db.jsondans les tutoriels.
Les routes que vous obtenez gratuitement
À partir du db.json ci-dessus, json-server génère une surface REST complète.
Pour le tableau posts :
GET /posts
GET /posts/:id
POST /posts
PUT /posts/:id
PATCH /posts/:id
DELETE /posts/:id
Pour l'objet profile :
GET /profile
PUT /profile
PATCH /profile
La requête est également intégrée. La syntaxe v1 utilise un deux-points pour les conditions :
GET /posts?views:gt=100 # vues supérieures à 100
GET /posts?views:lte=50 # vues inférieures ou égales à 50
GET /posts?_sort=-views # trier par vues, décroissant
GET /posts?_page=1&_per_page=25 # pagination
GET /posts?_embed=comments # inclure les commentaires liés
Les opérateurs disponibles incluent lt, lte, gt, gte, eq, ne, in, contains, startsWith et endsWith. Pour un fichier plat et une seule commande, c'est une sacrée API.
JSONPlaceholder : une fausse API sans aucune configuration
Parfois, vous ne voulez même pas installer un outil. JSONPlaceholder, du même auteur, est une fausse API REST gratuite hébergée sur jsonplaceholder.typicode.com. Vous l'appelez directement depuis votre code :
curl https://jsonplaceholder.typicode.com/posts/1
{
"userId": 1,
"id": 1,
"title": "sunt aut facere repellat provident",
"body": "quia et suscipit..."
}
Il est livré avec six ressources prêtes à l'emploi :
/posts(100 éléments)/comments(500)/albums(100)/photos(5000)/todos(200)/users(10)
Il accepte également les méthodes POST, PUT, PATCH et DELETE, mais voici le hic : les écritures sont simulées. L'API renvoie une réponse réaliste comme si le changement avait eu lieu, mais rien n'est enregistré. Actualisez et votre "nouveau" post aura disparu. C'est bien pour relier le code de l'interface utilisateur à des données prévisibles ; ce n'est pas un véritable backend.
json-server vs JSONPlaceholder
| json-server | JSONPlaceholder | |
|---|---|---|
| Configuration | Installer le package npm, écrire db.json |
Aucune, il suffit d'appeler l'URL |
| Exécution | Localement, votre machine | Hébergé, public |
| Données personnalisées | Oui, vos propres ressources | Non, ressources fixes |
| Les écritures persistent | Oui, vers db.json |
Non, simulées |
| Idéal pour | Prototypage avec vos propres formes | Démos rapides et apprentissage |
Utilisez JSONPlaceholder lorsque vous voulez des données immédiatement et que vous vous fichez de ce qu'elles sont. Utilisez json-server lorsque vous avez besoin de vos propres ressources et d'écritures qui persistent.
Où ces outils atteignent leurs limites
json-server et JSONPlaceholder sont excellents pour une chose : servir du JSON rapidement. Ils commencent à poser problème dès qu'un projet dépasse le simple prototype solo.
- Pas de véritable validation. Ils n'appliquent pas de schéma. Publiez une chaîne de caractères là où un nombre est attendu et elle sera joyeusement stockée. Votre API réelle la rejetterait.
- Pas de données dynamiques ou intelligentes. Les réponses sont ce qui se trouve dans le fichier. Il n'y a pas de moyen intégré de renvoyer un nouvel e-mail aléatoire ou une date future par requête.
- Local et mono-utilisateur. json-server s'exécute sur votre ordinateur portable. Un coéquipier ou une tâche d'intégration continue ne peut pas atteindre
localhost:3000. JSONPlaceholder est partagé, mais vous ne pouvez pas le personnaliser. - Écart par rapport à votre spécification. Les fausses données vivent dans un fichier séparé, déconnecté de votre contrat OpenAPI, de sorte que les deux s'écartent à mesure que l'API évolue.
- Écritures simulées (JSONPlaceholder). Tout ce qui est persistant, comme un panier ou un flux en plusieurs étapes, ne peut pas être testé avec.
Si vous avez dépassé les limites d'un fichier plat, nos récapitulatifs des outils de mocking d'endpoints REST et des serveurs mock d'API gratuits et bon marché couvrent le niveau supérieur, et la comparaison des outils de mocking d'API en ligne met les options hébergées côte à côte.
Quand passer à un vrai serveur mock
Un mock conscient des schémas corrige toutes les limitations ci-dessus. C'est là qu'Apidog prend le relais de json-server.

- Basé sur le schéma, pas sur le fichier. Définissez un endpoint (ou importez votre spécification OpenAPI) et Apidog le simule automatiquement. Le mock et le contrat restent synchronisés car ils partagent la même définition.
- Données intelligentes et dynamiques. Apidog lit les noms et types de champs et renvoie des valeurs réalistes : un e-mail valide pour un champ
email, une date pourcreatedAt, un nombre pourprice. Vous pouvez attacher des règles de style Faker par champ pour un contrôle total. Notre guide sur Faker.js dans Apidog et la présentation plus large du générateur de données de test approfondissent la production de valeurs réalistes. - Une URL cloud partageable. Apidog fournit au mock une URL hébergée que toute votre équipe et votre pipeline CI peuvent appeler, pas seulement
localhost. - Pas de Node requis. Il n'y a pas de package à installer par projet et pas de
db.jsonà gérer.
Simuler la même API dans Apidog
- Téléchargez Apidog et créez ou ouvrez un projet.
- Ajoutez un endpoint, par exemple
GET /posts, et définissez son schéma de réponse (ou importez un fichier OpenAPI existant). - Apidog génère une URL de mock et commence à renvoyer des données intelligentes et réalistes pour chaque champ immédiatement.
- Besoin de valeurs spécifiques ? Ajoutez une règle de mock par champ pour épingler la sortie.
- Partagez l'URL du mock avec votre équipe ou intégrez-la à votre suite de tests et CI.

Vous conservez la rapidité "API en quelques minutes" de json-server, et vous gagnez en validation, en données dynamiques et en une URL accessible à tous.
FAQ
json-server est-il gratuit ? Oui, il est open source et gratuit. JSONPlaceholder est également gratuit.
json-server persiste-t-il les données ? Oui. POST, PUT, PATCH et DELETE écrivent dans votre db.json, de sorte que les modifications survivent entre les requêtes tant que le serveur est en cours d'exécution. JSONPlaceholder simule les écritures et ne sauvegarde rien.
Puis-je utiliser json-server en production ? Non. Il est conçu pour le prototypage et les tests. Il n'a pas de véritable validation, d'authentification ou d'histoire de scalabilité.
Quelle est la différence entre json-server et un serveur mock comme Apidog ? json-server sert un fichier statique comme API. Apidog simule à partir de votre schéma d'API, renvoie des données réalistes dynamiques et expose une URL cloud partagée. Voir ce qu'est une API mock et le récapitulatif des outils de mocking REST pour le contexte.
Comment obtenir des fausses données réalistes au lieu de lignes statiques ? Utilisez un générateur. Un générateur de données de test crée des enregistrements variés et réalistes, et le mock d'Apidog le fait automatiquement à partir de votre schéma.
La version courte
json-server transforme un fichier JSON en une API REST fonctionnelle avec une seule commande, et JSONPlaceholder vous offre une fausse API hébergée sans aucune configuration. Les deux sont parfaits pour se débloquer rapidement. Une fois que vous avez besoin de validation de schéma, de données dynamiques, d'un état persistant et d'une URL que votre équipe peut réellement atteindre, un simple fichier ne suffit plus. C'est à ce moment-là que le serveur mock d'Apidog prend le relais. Téléchargez Apidog, importez votre spécification, et votre mock correspondra au contrat réel dès la première requête.
