Aller au contenu principal

Créer un serveur de simulation Postman

Ce guide explique comment utiliser les fichiers d'exemple Postman fournis pour simuler localement l'interface de programmation d'application (API) d'ingestion de logs Datadog. Vous pouvez vérifier les formats de requête, tester les réponses d'erreur et suivre les exemples du guide pratique sans envoyer de données vers un compte Datadog en production.

Prérequis​

  • Postman (version bureau ou web).

  • Trois fichiers JSON inclus dans ce projet :

    FichierObjectif
    DataPipeline-Environment.jsonDéfinit des variables réutilisables : dd_site, mock_base_url et dd_api_key.
    DataPipeline-postman-collection.jsonEnvoie des requêtes réelles à l'API d'ingestion de logs de Datadog (/api/v2/logs).
    DataPipeline-MockServer-Collection.jsonConfigure des réponses simulées pour les mêmes points de terminaison à l'aide d'un serveur de simulation Postman.

Téléchargez les trois fichiers : Télécharger les fichiers Postman.

1. Importez les fichiers dans Postman​

  1. Ouvrez Postman et cliquez sur Importer.
  2. Sélectionnez les trois fichiers JSON téléchargés en même temps.
  3. Dans le menu Environnement en haut à droite, sélectionnez Environnement de pipeline de données.

Une fois les fichiers importés, les éléments suivants apparaissent :

  • Projet de documentation du pipeline de données (collection d'API réelle).
  • Pipeline de données — Collection de serveurs fictifs.
  • Environnement de pipeline de données.

2. Créer le serveur fictif​

  1. Dans Postman, accédez à Serveurs fictifs dans la barre latérale gauche.
  2. Cliquez sur Créer un serveur fictif.
  3. Sélectionnez Pipeline de données — Collection de serveurs fictifs.
  4. Conservez les paramètres par défaut et cliquez sur Créer un serveur fictif.

Postman génère une adresse de serveur fictif unique, par exemple : https://a12b34cd-1234-5678.mock.pstmn.io

3. Mettre à jour la variable d'environnement​

  1. Accédez à Environnements > Environnement de pipeline de données.
  2. Recherchez la variable mock_base_url.
  3. Remplacez le paramètre par défaut par l'adresse du serveur fictif générée :
# Avant
https://mock-server-url-from-postman.io

# Après
https://a12b34cd-1234-5678.mock.pstmn.io
  1. Enregistrez l'environnement.

4. Envoyez votre première requête de simulation​

  1. Ouvrez POST /api/v2/logs dans la collection de serveurs de simulation.
  2. Vérifiez que l'environnement de pipeline de données est actif dans le menu en haut à droite.
  3. Cliquez sur Envoyer.

Le serveur de simulation renvoie une réponse simulée 202 Accepted, reflétant la véritable réponse Datadog : HTTP/1.1 202 Accepted

Note: The real Datadog Log Ingestion API returns a 202 Accepted with no response body. The mock collection returns a minimal JSON object for readability during testing:

{
  "status": "accepted",
  "message": "Événement de log reçu par le serveur de simulation."
}

5. Tester une réponse d'erreur​

Pour tester une réponse 400 bad request, supprimez le champ message du corps de la requête. Ce champ est obligatoire dans l'API d'ingestion de logs de Datadog.

Le serveur simulé renvoie le JSON suivant :

{
  "errors": ["Invalid JSON"]
}

Vous pouvez également tester une réponse 401 unauthorized en supprimant l'en-tête DD-API-KEY de la requête.

6. Basculer entre les tests en production et les tests simulés​

Les deux collections utilisent le même fichier d'environnement. Pour basculer entre les tests réels et les tests simulés, modifiez la collection que vous utilisez :

ObjectifCollectionVariable d'adresse de base
Test avec Datadog réelDataPipeline-postman-collection.json{{dd_site}} → datadoghq.com
Test local ou hors ligneDataPipeline-MockServer-Collection.json{{mock_base_url}} → votre adresse de simulation

Cette approche vous permet de vérifier les formats de requête et de réponse avant d'envoyer des données en production vers votre compte Datadog.

Visualisation du flux de requêtes​

Flux de requêtes du serveur de simulation Postman

Pourquoi est-ce important ?​

Cette configuration de serveur fictif illustre le même modèle de vérification que celui que vous utilisez lors du développement ou de la documentation d'une intégration API réelle :

  • Vérifiez la structure de la requête et les en-têtes requis (DD-API-KEY, Content-Type) avant d'envoyer du trafic réel.
  • Confirmez que les charges utiles JSON correspondent au schéma attendu : un tableau d'objets de journal, chacun comportant un champ message.
  • Testez la gestion des erreurs (400, 401, 429) sans épuiser le quota de l'API ni polluer un index de journaux de production.
  • Développez et vérifiez les exemples de documentation par rapport à un point de terminaison stable et reproductible.

Le même principe s'applique lors de la documentation du kit de développement logiciel (SDK) Galileo. Vous testez les fonctions instrumentées dans un flux de journaux dev avant de les faire passer en production, en vous assurant de configurer correctement les métriques d'évaluation avant que le trafic utilisateur réel ne passe par là.