DEV Community

Cover image for Cómo Configurar un Servidor Mock en la Nube Compartible con Apidog
Roobia
Roobia

Posted on • Originally published at apidog.com

Cómo Configurar un Servidor Mock en la Nube Compartible con Apidog

Tu equipo de frontend está bloqueado: el diseño está aprobado, las pantallas están a medio construir y la API todavía está a un sprint de distancia. Un mock local puede servir para depurar, pero deja de funcionar cuando cierras el portátil; también deja sin endpoint a QA, a otros desarrolladores y a cualquier socio que dependa de esa URL.

Prueba Apidog hoy

Apidog cubre esa brecha con Cloud Mock: genera una URL pública en mock.apidog.com que permanece disponible 24/7. Así, frontend, QA y socios pueden consumir respuestas realistas antes de que exista una implementación de backend. Si necesitas contexto sobre el enfoque, revisa qué es un mock de API y cuándo usarlo y la referencia de MDN sobre el modelo HTTP de solicitud/respuesta.

Qué es Cloud Mock y por qué un mock local no basta

Apidog genera un endpoint mock por cada API que diseñas. De forma predeterminada, el mock local responde desde tu instancia de Apidog mientras tu máquina está encendida. Es útil para trabajo individual, pero no para colaboración: si alguien más depende de la URL, tu disponibilidad se convierte en un requisito técnico.

Cloud Mock publica ese mock en la infraestructura alojada de Apidog. El endpoint sigue respondiendo aunque tu portátil esté apagado.

El flujo de trabajo es directo:

  1. Diseña el contrato del endpoint.
  2. Activa Cloud Mock en el proyecto.
  3. Copia la URL pública.
  4. Compártela con frontend, QA o integradores.

Esto permite que el frontend implemente pantallas con datos realistas y que QA prepare pruebas contra formas de respuesta ya definidas. Para equipos distribuidos, consulta cómo compartir servidores mock y entornos con equipos globales.

Habilita Cloud Mock y obtén una URL pública

Supongamos un servicio users con este endpoint:

GET /users
Enter fullscreen mode Exit fullscreen mode

El endpoint devuelve una lista de clientes. Sigue estos pasos para publicarlo como mock compartible.

Paso 1: activa Cloud Mock

En Apidog, abre el proyecto y ve a:

Project Settings > Feature Settings > Mock Settings

(Configuración del Proyecto > Configuración de Características > Configuración de Mocks)

Activa Cloud Mock.

Esta configuración se realiza una vez por proyecto. Después, cada endpoint tendrá una URL local y una URL de Cloud Mock.

Paso 2: copia la URL de Cloud Mock

Abre GET /users, entra en la pestaña Mock y copia la URL de Cloud Mock. Tendrá una forma similar a esta:

https://mock.apidog.com/m1/2689726-0-default/users?apidogToken=GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi
Enter fullscreen mode Exit fullscreen mode

La ruta sigue un patrón similar a:

mock.apidog.com/m1/<projectId>-<num>-<env>/<path>
Enter fullscreen mode Exit fullscreen mode

No construyas esta URL manualmente. Copia la URL generada por Apidog: es la referencia válida para tu proyecto, entorno y endpoint.

Paso 3: valida la respuesta desde Apidog

Antes de compartir la URL, prueba el endpoint desde la pestaña Mock. Envía una solicitud de prueba y comprueba que la respuesta coincide con el contrato esperado.

Por ejemplo, GET /users puede devolver:

[
  {
    "id": 1,
    "name": "Amelia Turner",
    "email": "amelia.turner@example.com",
    "city": "Portland"
  },
  {
    "id": 2,
    "name": "Marcus Bell",
    "email": "marcus.bell@example.com",
    "city": "Austin"
  }
]
Enter fullscreen mode Exit fullscreen mode

Apidog usa los nombres y tipos definidos en el esquema para generar datos plausibles. Esto es más útil que devolver valores genéricos como "string", especialmente al construir tablas, tarjetas, formularios y estados vacíos.

Paso 4: consume el mock desde el navegador o código

Para endpoints GET, pega la URL en el navegador para verificar rápidamente la respuesta JSON.

Para integrarlo en herramientas o scripts, úsala como cualquier endpoint HTTP:

curl "https://mock.apidog.com/m1/2689726-0-default/users?apidogToken=GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi"
Enter fullscreen mode Exit fullscreen mode

En resumen: diseña el endpoint, activa Cloud Mock, copia la URL y comparte el contrato ejecutable con el equipo.

Protege el mock con autenticación por token

Una URL pública es práctica, pero puede requerir protección si representa una funcionalidad no lanzada o una integración privada.

Ve a:

Project Settings > Feature Settings > Mock Settings

Configura el permiso de acceso como Token Authentication (Autenticación por Token). A partir de ese momento, las solicitudes deben incluir un apidogToken válido.

Puedes enviar el token de tres formas.

Opción 1: como parámetro de consulta

curl "https://mock.apidog.com/m1/2689726-0-default/users?apidogToken=GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi"
Enter fullscreen mode Exit fullscreen mode

Opción 2: como encabezado HTTP

Esta opción evita incluir el token en la URL:

curl "https://mock.apidog.com/m1/2689726-0-default/users" \
  -H "apidogToken: GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi"
Enter fullscreen mode Exit fullscreen mode

Opción 3: como campo del cuerpo

También puedes enviar apidogToken como parámetro del cuerpo en solicitudes form-data o x-www-form-urlencoded.

En aplicaciones frontend, el encabezado suele ser la opción más limpia:

const res = await fetch(
  "https://mock.apidog.com/m1/2689726-0-default/users",
  {
    headers: {
      apidogToken: "GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi"
    }
  }
);

const users = await res.json();
Enter fullscreen mode Exit fullscreen mode

Si activas la autenticación por token después de compartir una URL sin protección, coordina el cambio con los consumidores. De lo contrario, sus llamadas comenzarán a fallar hasta que agreguen el token.

Genera datos realistas por región con locales

Un mock con valores como "name": "string" no permite detectar problemas reales de interfaz. En cambio, nombres, direcciones y teléfonos plausibles ayudan a encontrar:

  • Desbordamientos de texto.
  • Problemas de codificación.
  • Errores de formato de direcciones o números.
  • Comportamientos inesperados con scripts no latinos.
  • Suposiciones incorrectas sobre longitud de campos.

Apidog utiliza Faker.js para generar datos mock, incluyendo controles de localización.

Define el locale predeterminado del proyecto

De forma predeterminada, Faker sigue el idioma configurado en:

Project Settings > Basic Settings

(Configuración del Proyecto > Configuración Básica)

Ese idioma se convierte en el locale predeterminado de los datos mock generados. Por ejemplo, si el proyecto está configurado en francés, los nombres y direcciones generados reflejarán esa configuración.

Anula el locale para todo el proyecto

Si necesitas una región distinta del idioma del proyecto, ve a:

Project Settings > Feature Settings > Mock Settings

Selecciona un locale de Faker en el menú correspondiente. Esta configuración prevalece sobre el idioma definido en Basic Settings para todos los campos del proyecto.

Este ajuste es útil para probar internacionalización. Por ejemplo, al configurar una región japonesa puedes validar cómo responde tu UI ante nombres, direcciones y formatos diferentes.

Para profundizar en la generación basada en esquemas, consulta el mock inteligente de Apidog y cómo lee tu esquema.

Anula el locale por campo

También puedes configurar un locale específico dentro de una expresión mock:

{{$person.fullName(locale='ja')}}
Enter fullscreen mode Exit fullscreen mode

Esto puede generar un nombre como:

田中 太郎
Enter fullscreen mode Exit fullscreen mode

El resto de la respuesta seguirá usando el locale configurado para el proyecto.

La prioridad es:

  1. Locale definido en el campo.
  2. Locale definido en Mock Settings.
  3. Idioma predeterminado de Basic Settings.

La documentación muestra ja como ejemplo, pero no publica una lista completa de locales compatibles. Confirma el código que necesitas en la documentación de mock de Apidog y en la referencia de localización de Faker.js.

Configura también la zona horaria

En Project Settings > Feature Settings > Mock Settings también puedes definir una zona horaria predeterminada. Para casos concretos, puedes anularla por campo mediante el parámetro timeZone dentro de una expresión mock.

Esto resulta importante si tu frontend renderiza campos como createdAt, updatedAt o fechas de agenda. Mantener una zona horaria coherente evita que los datos generados parezcan pertenecer a otra región.

Para más escenarios, revisa estos casos de uso prácticos de mocking de API.

Cloud Mock frente a un mock autoalojado

Cloud Mock es la opción alojada de Apidog y funciona bien para la mayoría de equipos: no requiere operar infraestructura y permanece disponible de forma continua.

Sin embargo, algunas organizaciones tienen requisitos de residencia de datos o políticas que impiden enviar tráfico de prueba a la nube de un proveedor. En esos casos, Apidog también permite ejecutar el servicio mock en infraestructura propia.

La decisión es simple:

Opción Ventaja principal Coste operativo
Cloud Mock Configuración rápida y disponibilidad continua Dependes del servicio alojado
Mock autoalojado Mayor control sobre infraestructura y datos Debes operar el servicio

Si necesitas esta segunda opción, consulta cómo autoalojar el servidor mock de Apidog. Para evaluar alternativas alojadas, revisa esta comparación de herramientas de mocking de API en línea.

La disponibilidad de funciones puede variar según la cuenta y el espacio de trabajo. Verifica la configuración disponible en tu entorno. Puedes descargar Apidog y probar el flujo completo.

Automatiza el flujo con la CLI de Apidog

Cloud Mock no se inicia desde una terminal: las respuestas mock se generan a partir del esquema del endpoint y se sirven desde el motor alojado de Apidog.

La CLI de Apidog no ejecuta un servidor mock, pero ayuda a mantener actualizada la fuente de verdad que el mock consume: la definición de endpoints y esquemas.

Puedes usar la CLI y agentes de código como Cursor o Claude Code para crear o actualizar endpoints. Cuando agregas un campo al contrato, Cloud Mock puede reflejarlo al generar respuestas basadas en ese esquema.

Cuando el backend real esté listo, ejecuta los escenarios de prueba guardados contra el entorno correspondiente:

apidog run -t <scenario_id> -e <env_id> -r cli
Enter fullscreen mode Exit fullscreen mode

Este comando ejecuta un escenario de prueba contra un entorno e informa los resultados. Así, el contrato que permitió al frontend avanzar con mocks también sirve para validar el backend implementado.

En lugar de escribir los identificadores manualmente, abre el escenario en Apidog y copia el comando generado con -t y -e ya completados. Para integrarlo en automatización, consulta la guía para ejecutar Apidog en una pipeline de CI/CD.

Preguntas frecuentes

¿La URL de Cloud Mock sigue funcionando cuando cierro Apidog?

Sí. Esa es la diferencia principal con un mock local. Cloud Mock se sirve desde la infraestructura de Apidog y permanece disponible aunque tu computadora esté apagada.

¿Puedo abrir la URL del mock directamente en un navegador?

Sí, para solicitudes GET. Pega la URL completa, incluido apidogToken si aplica, y el navegador mostrará la respuesta JSON.

Para otros métodos HTTP, o para evitar exponer el token en el historial del navegador, usa curl, un cliente HTTP o tu aplicación frontend con el token en un encabezado.

¿Qué ocurre si una solicitud no incluye el token?

Si activaste Token Authentication, las solicitudes sin un apidogToken válido serán rechazadas. Puedes proporcionarlo en la URL, en un encabezado o en el cuerpo de una solicitud de formulario.

¿Cómo genero datos mock de un país concreto?

Tienes tres niveles de configuración:

  1. Define el idioma del proyecto en Basic Settings.
  2. Define un locale global en Mock Settings.
  3. Define un locale por campo mediante una expresión mock.

Ejemplo:

{{$person.fullName(locale='ja')}}
Enter fullscreen mode Exit fullscreen mode

La configuración de campo tiene prioridad sobre la del proyecto. El tutorial de mock inteligente explica cómo esta generación se relaciona con tu esquema.

¿Cuándo debería usar Cloud Mock frente a una herramienta sin interfaz gráfica?

Cloud Mock es adecuado cuando quieres un endpoint alojado, compartible y vinculado al diseño de tu API.

Si necesitas mocks integrados directamente en una compilación automatizada sin GUI, revisa esta comparación de herramientas de mock sin interfaz gráfica. Muchas de estas herramientas se basan en contratos OpenAPI; la OpenAPI Initiative es una referencia útil para mantener una especificación clara.

Conclusión

Un mock que vive solo en tu portátil desbloquea a una persona. Cloud Mock lo convierte en una URL pública de mock.apidog.com que puede usar todo el equipo.

El flujo es práctico:

  1. Diseña el endpoint.
  2. Activa Cloud Mock.
  3. Genera y valida la respuesta.
  4. Protege el acceso con token si es necesario.
  5. Comparte la URL con frontend, QA e integradores.

Con locales y zonas horarias, también puedes probar interfaces con datos más cercanos a los usuarios reales. Descarga Apidog para crear tu primer mock en la nube compartible.

Top comments (0)