Saltar al contenido principal

Crear un servidor de simulación de Postman

Esta guía explica cómo utilizar los archivos de ejemplo de Postman proporcionados para simular localmente la interfaz de programación de aplicaciones (API) de Datadog Log Ingestion. Puede verificar los formatos de solicitud, probar las respuestas de error y seguir los ejemplos de la guía práctica sin enviar datos a una cuenta de Datadog activa.

Requisitos previos

  • Postman (versión de escritorio o web).

  • Tres archivos JSON incluidos en este proyecto:

    ArchivoFinalidad
    DataPipeline-Environment.jsonDefine variables reutilizables: dd_site, mock_base_url y dd_api_key.
    DataPipeline-postman-collection.jsonEnvía solicitudes reales a la API de ingesta de logs de Datadog (/api/v2/logs).
    DataPipeline-MockServer-Collection.jsonConfigura respuestas simuladas para los mismos puntos de conexión utilizando un servidor simulado de Postman.

Descarga los tres archivos: Descargar archivos de Postman.

1. Importa los archivos a Postman

  1. Abre Postman y haz clic en Importar.
  2. Selecciona los tres archivos JSON descargados a la vez.
  3. En el menú de entorno de la esquina superior derecha, selecciona Entorno de canalización de datos.

Una vez importados los archivos, aparecerán los siguientes elementos:

  • Proyecto de documentación de canalización de datos (colección de API real).
  • Canalización de datos — Colección de servidor simulado.
  • Entorno de canalización de datos.

2. Crea el servidor simulado

  1. En Postman, ve a Servidores simulados en la barra lateral izquierda.
  2. Haz clic en Crear servidor simulado.
  3. Selecciona Canalización de datos — Colección de servidores simulados.
  4. Mantén la configuración predeterminada y haz clic en Crear servidor simulado.

Postman genera una dirección de servidor simulado única, por ejemplo: https://a12b34cd-1234-5678.mock.pstmn.io

3. Actualizar la variable de entorno

  1. Ve a Entornos > Entorno de canalización de datos.
  2. Busca la variable mock_base_url.
  3. Sustituya el marcador de posición por la dirección del servidor simulado generada:
# Antes
https://mock-server-url-from-postman.io

# Después
https://a12b34cd-1234-5678.mock.pstmn.io
  1. Guarde el entorno.

4. Envía tu primera solicitud simulada

  1. Abre POST /api/v2/logs dentro de la Colección de servidores simulados.
  2. Confirma que el Entorno de canalización de datos está activo en el menú superior derecho.
  3. Haz clic en Enviar.

El servidor simulado devuelve una respuesta simulada 202 Accepted, que refleja la respuesta real de 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": "Log event received by mock server."
}

5. Probar una respuesta de error

Para probar una respuesta 400 bad request, elimina el campo message del cuerpo de la solicitud. Este campo es obligatorio en la API de ingestión de logs de Datadog.

El servidor simulado devuelve el siguiente JSON:

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

También puede probar una respuesta 401 unauthorized eliminando el encabezado DD-API-KEY de la solicitud.

6. Cambiar entre pruebas en vivo y simuladas

Ambas colecciones utilizan el mismo archivo de entorno. Para cambiar entre pruebas reales y simuladas, cambie la colección que utiliza:

ObjetivoColecciónVariable de dirección base
Prueba con Datadog realDataPipeline-postman-collection.json{{dd_site}}datadoghq.com
Prueba local o sin conexiónDataPipeline-MockServer-Collection.json{{mock_base_url}} → tu dirección simulada

Este enfoque te permite verificar los formatos de solicitud y respuesta antes de enviar datos en tiempo real a tu cuenta de Datadog.

Visualización del flujo de solicitudes

Flujo de solicitudes del servidor simulado de Postman

Por qué es importante

Esta configuración del servidor simulado muestra el mismo patrón de verificación que se utiliza al desarrollar o documentar una integración de API real:

  • Verifica la estructura de la solicitud y los encabezados requeridos (DD-API-KEY, Content-Type) antes de enviar tráfico en vivo.
  • Confirma que las cargas útiles JSON coincidan con el esquema esperado: una matriz de objetos de registro, cada uno con un campo message.
  • Prueba el manejo de errores (400, 401, 429) sin consumir la cuota de la API ni contaminar un índice de registros de producción.
  • Desarrolla y verifica los ejemplos de la documentación con un punto final estable y reproducible.

El mismo patrón se aplica al documentar el kit de desarrollo de software (SDK) de Galileo. Pruebas las funciones instrumentadas en un flujo de registros dev antes de pasarlas a producción, asegurándote de configurar correctamente las métricas de evaluación antes de que fluya el tráfico real de usuarios.