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​

Téléchargez les trois fichiers d'exemple :

Vous pouvez également consulter les fichiers d'exemple sur GitHub.

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 :
mock_base_url
# Before
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

Remarque : L'API d'ingestion des logs Datadog réelle renvoie un code d'état 202 Accepted sans corps de réponse. La simulation renvoie un objet JSON minimal pour faciliter la lecture pendant les tests :

Response: 202 Accepted
{
  "status": "accepted",
  "message": "Log event received by mock server."
}

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 :

Response: 400 Bad Request
{
  "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à.

Prochaines étapes​