DEV Community

Cover image for Comment tester une API simulée (et créer votre propre API de test au besoin)
Antoine Laurent
Antoine Laurent

Posted on • Originally published at apidog.com

Comment tester une API simulée (et créer votre propre API de test au besoin)

Lorsque vous construisez un frontend, déboguez un client HTTP ou apprenez une nouvelle bibliothèque de requêtes, vous avez souvent besoin d’un endpoint qui renvoie du JSON réaliste sans créer de backend. Une API factice (dummy API) fournit ce point d’accès public, gratuit et immédiatement appelable. Ce guide liste les meilleures API factices publiques, montre comment les utiliser dans votre code, puis explique quand passer à votre propre fausse API REST avec un outil comme Apidog. Pour revoir les bases côté navigateur, le guide MDN sur l’utilisation de l’API Fetch complète bien les exemples ci-dessous.

Essayez Apidog aujourd’hui

Qu’est-ce qu’une API factice ?

Une API factice est un service hébergé qui renvoie des données JSON préenregistrées pour des ressources courantes : utilisateurs, publications, produits, paniers, tâches, commentaires, etc.

Vous n’avez généralement pas besoin :

  • de créer un compte ;
  • d’héberger un serveur ;
  • de connecter une base de données ;
  • de risquer de casser des données de production.

La plupart de ces services acceptent les méthodes HTTP classiques :

GET
POST
PUT
PATCH
DELETE
Enter fullscreen mode Exit fullscreen mode

Mais les écritures sont presque toujours simulées. Par exemple, un POST /posts peut renvoyer un nouvel id, sans rien enregistrer réellement côté serveur.

Utilisez donc une API factice pour :

  • prototyper rapidement une interface ;
  • tester votre logique fetch, axios ou requests ;
  • apprendre à consommer une API REST ;
  • créer des démos ou des tests simples.

Évitez-la dès que vous avez besoin :

  • d’un état persistant ;
  • de votre propre schéma métier ;
  • de réponses d’erreur contrôlées ;
  • de règles d’authentification réalistes.

Les meilleures API factices gratuites pour tester

Voici trois API publiques fiables pour démarrer rapidement, sans backend.

1. JSONPlaceholder

JSONPlaceholder est le classique pour les démos REST.

Il expose plusieurs ressources liées :

  • posts
  • comments
  • albums
  • photos
  • todos
  • users

Exemple avec curl :

curl https://jsonplaceholder.typicode.com/posts/1
Enter fullscreen mode Exit fullscreen mode

Réponse typique :

{
  "userId": 1,
  "id": 1,
  "title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
  "body": "quia et suscipit..."
}
Enter fullscreen mode Exit fullscreen mode

Vous pouvez aussi tester les relations :

curl https://jsonplaceholder.typicode.com/posts/1/comments
Enter fullscreen mode Exit fullscreen mode

Ou simuler une création :

curl -X POST https://jsonplaceholder.typicode.com/posts \
  -H "Content-Type: application/json" \
  -d '{"title":"Hello","body":"Demo","userId":1}'
Enter fullscreen mode Exit fullscreen mode

Le serveur renvoie un objet avec un faux identifiant, mais il ne persiste pas la donnée.

2. DummyJSON

DummyJSON est plus riche si vous construisez une interface proche d’un vrai produit.

Il propose notamment :

  • produits ;
  • paniers ;
  • utilisateurs ;
  • publications ;
  • commentaires ;
  • citations ;
  • tâches ;
  • recettes ;
  • authentification avec jeton.

Exemple : récupérer un produit.

curl https://dummyjson.com/products/1
Enter fullscreen mode Exit fullscreen mode

Exemple : rechercher des produits.

curl "https://dummyjson.com/products/search?q=phone"
Enter fullscreen mode Exit fullscreen mode

Exemple : tester un login.

curl -X POST https://dummyjson.com/auth/login \
  -H "Content-Type: application/json" \
  -d '{
    "username": "emilys",
    "password": "emilyspass"
  }'
Enter fullscreen mode Exit fullscreen mode

Ce flux est pratique pour tester :

  • le stockage d’un jeton ;
  • les appels authentifiés ;
  • les écrans de connexion ;
  • les états de chargement et d’erreur côté frontend.

3. reqres.in

reqres.in est conçu pour tester les cycles requête/réponse :

  • pagination ;
  • utilisateur unique ;
  • création ;
  • mise à jour ;
  • suppression ;
  • inscription ;
  • connexion ;
  • réponses différées.

Important : le niveau gratuit attend maintenant un en-tête de clé API.

curl https://reqres.in/api/users/2 \
  -H "x-api-key: reqres-free-v1"
Enter fullscreen mode Exit fullscreen mode

Sans cet en-tête, vous pouvez obtenir une réponse 401.

Exemple de pagination :

curl "https://reqres.in/api/users?page=2" \
  -H "x-api-key: reqres-free-v1"
Enter fullscreen mode Exit fullscreen mode

Comparatif rapide

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, avec jeton Simulée, non enregistrée
reqres.in Pagination, inscription, connexion En-tête de clé API Simulée, non enregistrée

Si vous cherchez plus d’options, le récapitulatif des API publiques pour les tests couvre des cas plus spécialisés. La liste des API publiques gratuites pour les développeurs est aussi utile si vous avez besoin de données thématiques comme la météo, les devises ou d’autres domaines.

Appeler une API factice en JavaScript

Une API factice s’appelle comme n’importe quelle API HTTP.

Exemple avec fetch :

const response = await fetch('https://dummyjson.com/users/1');

if (!response.ok) {
  throw new Error(`HTTP error: ${response.status}`);
}

const user = await response.json();

console.log(user.firstName);
console.log(user.email);
Enter fullscreen mode Exit fullscreen mode

Créer une ressource simulée :

const response = await fetch('https://dummyjson.com/users/add', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    firstName: 'Ada',
    lastName: 'Lovelace',
    email: 'ada@example.com',
  }),
});

const createdUser = await response.json();

console.log(createdUser);
Enter fullscreen mode Exit fullscreen mode

La réponse contient un objet avec un identifiant généré, mais cette création n’est pas persistée.

Appeler une API factice avec Axios

Si votre projet utilise Axios :

import axios from 'axios';

const { data } = await axios.get('https://jsonplaceholder.typicode.com/todos/1');

console.log(data);
Enter fullscreen mode Exit fullscreen mode

Exemple avec gestion d’erreur :

import axios from 'axios';

try {
  const { data } = await axios.get('https://dummyjson.com/products/1');
  console.log(data.title);
} catch (error) {
  if (error.response) {
    console.error('Erreur HTTP:', error.response.status);
  } else {
    console.error('Erreur réseau:', error.message);
  }
}
Enter fullscreen mode Exit fullscreen mode

Appeler une API factice en Python

Avec requests :

import requests

response = requests.get("https://jsonplaceholder.typicode.com/todos/1")
response.raise_for_status()

todo = response.json()

print(todo)
Enter fullscreen mode Exit fullscreen mode

Créer une ressource simulée :

import requests

payload = {
    "title": "Nouvelle tâche",
    "completed": False,
    "userId": 1
}

response = requests.post(
    "https://jsonplaceholder.typicode.com/todos",
    json=payload
)

response.raise_for_status()

print(response.json())
Enter fullscreen mode Exit fullscreen mode

Pour obtenir des données crédibles dans vos tests, le guide sur la création de données de test d’API réalistes montre comment générer des noms, e-mails et horodatages plus proches d’un trafic réel que des valeurs comme test123.

Exemple frontend simple avec état de chargement

Voici un exemple React minimal pour consommer une API factice.

import { useEffect, useState } from 'react';

export default function ProductCard() {
  const [product, setProduct] = useState(null);
  const [status, setStatus] = useState('loading');
  const [error, setError] = useState(null);

  useEffect(() => {
    async function loadProduct() {
      try {
        const response = await fetch('https://dummyjson.com/products/1');

        if (!response.ok) {
          throw new Error(`Erreur HTTP ${response.status}`);
        }

        const data = await response.json();

        setProduct(data);
        setStatus('success');
      } catch (err) {
        setError(err.message);
        setStatus('error');
      }
    }

    loadProduct();
  }, []);

  if (status === 'loading') return <p>Chargement...</p>;
  if (status === 'error') return <p>Erreur : {error}</p>;

  return (
    <article>
      <h2>{product.title}</h2>
      <p>{product.description}</p>
      <strong>{product.price} €</strong>
    </article>
  );
}
Enter fullscreen mode Exit fullscreen mode

Ce type d’exemple suffit pour valider :

  • votre logique d’appel API ;
  • vos états loading, success, error ;
  • votre rendu de données JSON ;
  • votre structure de composant.

Quand une API factice publique ne suffit plus

Les API factices publiques sont utiles au début, mais elles deviennent limitées dès que votre projet a des exigences précises.

1. Votre schéma ne correspond pas

Votre application attend peut-être :

{
  "id": "cus_123",
  "subscription_tier": "pro",
  "billing": {
    "status": "active",
    "renewalDate": "2026-07-01"
  }
}
Enter fullscreen mode Exit fullscreen mode

JSONPlaceholder ne renverra jamais ce type de structure. Vous devrez adapter votre frontend à des données qui ne ressemblent pas à votre vraie API, ce qui peut créer de mauvaises hypothèses.

2. Vous avez besoin d’un état

Un vrai panier doit évoluer :

  1. l’utilisateur ajoute un produit ;
  2. le total change ;
  3. la quantité est mise à jour ;
  4. le panier reste disponible au prochain appel.

Une API factice publique renvoie souvent votre POST, puis oublie immédiatement l’opération.

3. Vous devez tester les erreurs

Dans une vraie application, vous devez gérer :

  • 400 Bad Request ;
  • 401 Unauthorized ;
  • 403 Forbidden ;
  • 404 Not Found ;
  • 429 Too Many Requests ;
  • 500 Internal Server Error ;
  • réponses lentes ;
  • corps JSON mal formés.

Les services publics ne vous donnent pas toujours le contrôle nécessaire pour reproduire ces scénarios.

4. Le backend n’existe pas encore

Frontend et backend sont souvent développés en parallèle. Dans ce cas, l’équipe frontend a besoin d’endpoints conformes au contrat prévu, avant que le backend soit prêt.

C’est le moment de passer d’une API empruntée à une API simulée conçue pour les tests.

Construire votre propre fausse API avec Apidog

Apidog combine conception d’API, tests, débogage et simulation dans une même plateforme.

Le principe est simple : vous définissez votre contrat d’API, puis Apidog génère des réponses simulées à partir du schéma.

Voici le workflow court.

Étape 1 : créer ou importer un endpoint

Vous pouvez :

  • créer une API directement dans Apidog ;
  • importer une spécification OpenAPI ;
  • importer un fichier Swagger existant.

Exemple de schéma attendu :

{
  "id": "string",
  "email": "string",
  "createdAt": "string",
  "subscription_tier": "string"
}
Enter fullscreen mode Exit fullscreen mode

Apidog utilise ce schéma pour générer des réponses cohérentes avec votre contrat.

Étape 2 : générer des données factices réalistes

La simulation intelligente peut déduire des valeurs selon les noms de champs.

Par exemple :

  • email → adresse e-mail ;
  • createdAt → horodatage ;
  • price → nombre ;
  • country → nom de pays ;
  • firstName → prénom.

Vous pouvez ajuster les règles champ par champ pour éviter les valeurs trop génériques.

Étape 3 : appeler l’URL de simulation

Apidog fournit une URL de mock pour chaque endpoint. Vous pouvez l’utiliser comme une vraie API depuis :

  • votre frontend ;
  • vos tests automatisés ;
  • Postman ou curl ;
  • un script CI ;
  • un client mobile.

Exemple côté frontend :

const response = await fetch('https://votre-url-de-mock.example.com/customers/123');
const customer = await response.json();

console.log(customer.subscription_tier);
Enter fullscreen mode Exit fullscreen mode

La différence avec une API factice publique : la réponse correspond à votre contrat, pas à un modèle générique.

Étape 4 : ajouter des erreurs et comportements spécifiques

Vous pouvez configurer des scénarios comme :

  • une réponse 404 pour un identifiant inconnu ;
  • une réponse 500 pour tester une erreur serveur ;
  • un délai artificiel pour tester un spinner ;
  • une réponse différente selon un paramètre ;
  • un corps JSON spécifique pour valider un cas métier.

Cela permet de tester vos branches de code avant que le backend existe.

Exemple de logique à valider côté client :

async function getCustomer(id) {
  const response = await fetch(`/customers/${id}`);

  if (response.status === 404) {
    return null;
  }

  if (!response.ok) {
    throw new Error(`Erreur API: ${response.status}`);
  }

  return response.json();
}
Enter fullscreen mode Exit fullscreen mode

Une API publique générique ne vous donne pas toujours ce niveau de contrôle.

Pour aller plus loin, la présentation sur la génération de données de simulation à partir de schémas OpenAPI détaille l’utilisation de règles de génération basées sur le schéma.

API factice publique vs simulateur Apidog

Besoin API factice publique Simulateur Apidog
Données JSON rapides Excellent Excellent
Vos formes de données exactes Non Oui
Réponses d’erreur personnalisées Non Oui
Délais simulés Limité Oui
Contrat OpenAPI respecté Non Oui
Configuration Zéro Quelques minutes

Le bon choix dépend du contexte :

  • utilisez une API factice publique pour une expérimentation rapide ;
  • utilisez votre propre simulation quand le contrat, les erreurs et les données métier comptent.

Dans une équipe produit, les deux approches peuvent coexister : API publiques pour les tests jetables, mocks projet pour le développement sérieux.

Bonnes pratiques avec les API factices

Ne jamais envoyer de vraies données

N’envoyez pas :

  • données utilisateur réelles ;
  • mots de passe ;
  • secrets ;
  • jetons ;
  • clés API privées ;
  • données personnelles.

Traitez toute API publique comme un environnement non fiable.

Encapsuler les appels HTTP

Évitez de disperser les URLs partout dans vos composants.

Préférez un client API :

const API_BASE_URL = import.meta.env.VITE_API_BASE_URL;

export async function getProduct(id) {
  const response = await fetch(`${API_BASE_URL}/products/${id}`);

  if (!response.ok) {
    throw new Error(`Erreur HTTP ${response.status}`);
  }

  return response.json();
}
Enter fullscreen mode Exit fullscreen mode

Ainsi, vous pouvez passer facilement :

  • d’une API factice publique ;
  • à un mock Apidog ;
  • puis au vrai backend.

Utiliser des variables d’environnement

Exemple :

VITE_API_BASE_URL=https://dummyjson.com
Enter fullscreen mode Exit fullscreen mode

Puis plus tard :

VITE_API_BASE_URL=https://votre-url-de-mock.apidog.example
Enter fullscreen mode Exit fullscreen mode

Et en production :

VITE_API_BASE_URL=https://api.votre-produit.com
Enter fullscreen mode Exit fullscreen mode

Votre code applicatif ne change pas.

Foire aux questions

Une API factice est-elle la même chose qu’une API simulée ?

Elles se recoupent, mais ne sont pas identiques.

Une API factice désigne souvent un service public partagé avec des données génériques, comme JSONPlaceholder.

Une API simulée est une API que vous contrôlez : schéma, réponses, erreurs, délais et comportements. Une API factice publique est donc une forme de simulation déjà hébergée par quelqu’un d’autre.

Pour plus de détails, consultez l’article sur ce qu’est une API simulée.

Les fausses API gratuites sont-elles sûres avec des données réelles ?

Non.

N’envoyez jamais de données réelles à une API factice publique. Utilisez uniquement des valeurs de test jetables. Si vous avez besoin de confidentialité, de contrôle ou de persistance, utilisez votre propre simulation ou un backend dédié.

Les API factices enregistrent-elles les données envoyées ?

Presque jamais.

JSONPlaceholder, DummyJSON et reqres.in acceptent les requêtes d’écriture et renvoient une réponse simulée, mais les données ne persistent pas. Si vous rechargez ou relisez la collection, votre ressource créée n’existe généralement plus.

Puis-je créer une fausse API sans écrire de code serveur ?

Oui.

Avec Apidog, vous définissez le schéma de l’endpoint ou importez une spécification OpenAPI, puis vous utilisez la simulation pour obtenir des endpoints appelables sans écrire de serveur.

En résumé

Les API factices publiques comme JSONPlaceholder, DummyJSON et reqres.in sont idéales pour obtenir rapidement du JSON réaliste, prototyper une interface ou tester un client HTTP.

Elles montrent leurs limites dès que vous avez besoin :

  • de votre propre schéma ;
  • d’un état persistant ;
  • de réponses d’erreur contrôlées ;
  • d’un contrat OpenAPI respecté ;
  • d’un mock utilisable par toute l’équipe.

Dans ce cas, créez une fausse API que vous contrôlez. Avec Apidog, vous pouvez importer votre spécification, générer des données simulées pilotées par schéma et appeler vos endpoints de mock en quelques minutes. Téléchargez Apidog pour transformer votre prochain contrat API en simulation fonctionnelle avant même que le backend soit prêt.

Top comments (0)