API Pública y CLI

Automatiza la generación de mocks y entornos de prueba utilizando la herramienta CLI oficial o peticiones curl directas.

Crear un mock a mano está bien una vez. Cuando cada ejecución de CI, cada prueba de integración y cada vista previa de rama quiere su propio endpoint desechable, lo que quieres es un script. La API pública es un único POST sin autenticación que devuelve una URL y un token de administrador de un solo uso, y la CLI quickmock es una envoltura fina sobre esa misma llamada. Cualquiera de las dos convierte un mock en algo que tu pipeline crea, usa y descarta sin que nadie abra un navegador.

¿Cómo se instala la CLI?

La CLI es un único binario de Go sin dependencias en tiempo de ejecución. Se instala con el toolchain de Go:

go install github.com/Deadsquirrel93/quickmock.dev/cmd/quickmock@latest

Eso deja un ejecutable quickmock en $(go env GOPATH)/bin. Añade ese directorio a tu PATH si no está ya — una instalación recién hecha de Go suele dejarlo fuera, y un command not found justo después de un go install correcto es casi siempre esto y nada más.

No hay nada que instalar del lado del servidor ni ningún archivo de configuración que escribir. Si ejecutas tu propia instancia de Quickmock en lugar de quickmock.dev, apunta la CLI hacia ella con -url; el resto de flags se comportan igual.

¿Qué hace exactamente la CLI?

Todo el trabajo está en un subcomando. create toma los mismos campos que la API, en forma de flags:

quickmock create -m POST -s 201 -c application/json \
  -H 'X-Request-Id: abc' \
  -b '{"status":"created"}'

Imprime dos líneas: la URL pública del mock y su token de administrador de un solo uso. La URL es lo que llamarán tus pruebas. El token es lo que después te permite editar, extender o eliminar el mock y leer su registro privado: se muestra exactamente una vez y no se puede recuperar, así que captúralo en el mismo paso que crea el mock y no en uno posterior.

Repite -H por cada cabecera de respuesta que quieras, igual que harías con curl. Un valor sin dos puntos se rechaza en vez de ignorarse, así que una errata hace fallar el paso en lugar de producir en silencio un mock al que le falta una cabecera.

¿Cómo se crea un mock desde un pipeline?

En un pipeline la CLI suele ser una dependencia de más, y la API es una sola petición. Crea el mock en un paso de preparación, pasa la URL a lo que venga después y deja que el TTL recoja por ti:

MOCK=$(curl -s -X POST https://quickmock.dev/api/mocks \
  -H 'Content-Type: application/json' \
  -d '{"method":"GET","response_status":200,"ttl_seconds":3600}')
echo "MOCK_URL=$(echo "$MOCK" | jq -r .url)" >> "$GITHUB_ENV"

Ajusta ttl_seconds a lo que realmente dura el trabajo. Un mock creado con un TTL de una hora desaparece solo, lo que significa que un trabajo cancelado o fallido no deja nada detrás y nunca necesitas un paso de limpieza que podría no llegar a ejecutarse.

Y de paso, mantén el token de administrador fuera del log. curl -s pasado por jq -r .url imprime solo la URL; volcar el cuerpo entero de la respuesta escribe una credencial válida en un log de compilación que puede leer cualquiera con acceso al proyecto.

¿Qué suele salir mal?

  • Tirar el token de administrador. Aparece en la respuesta de creación y en ningún otro sitio. Sin él no puedes editar ni eliminar el mock, ni leer sus registros privados: solo esperar a que expire.
  • Un mock por caso de prueba. El límite de mocks activos por IP es real, y un runner de CI es una sola IP. Crea un mock por trabajo y separa los casos con variantes con nombre o con rutas.
  • Fijar el slug en el código. Los slugs se asignan, no se eligen. Lee el campo url de la respuesta y pasa ese valor.
  • Sin TTL. Sin ttl_seconds el mock vive según el valor por defecto del servidor, mucho después de que haya terminado el trabajo que lo necesitaba.

Cuándo usar esto

La creación manual está bien para prototipado rápido, pero los pipelines CI/CD y los tests automatizados requieren entornos reproducibles. La API y el CLI te permiten automatizar la creación y eliminación de mocks, inyectando las URLs generadas directamente en tus tests.

Crear el mock

curl -X POST https://quickmock.dev/api/mocks \
  -H 'Content-Type: application/json' \
  -d '{
  "method": "POST",
  "response_status": 201,
  "response_body": "{\"status\":\"created\"}"
}'

Llamarlo

curl -X POST https://quickmock.dev/m/<slug>

Lo que obtienes

{"status":"created"}

Preguntas frecuentes

¿Necesito una cuenta o una clave de API?
No. POST /api/mocks no requiere autenticación: crear un mock no necesita nada más que la propia petición. La autenticación entra en juego después — el token de administrador que devuelve esa llamada es lo que protege la edición, el borrado y el inspector privado del mock que acabas de crear.
¿Cómo elimino el mock cuando termina el trabajo?
Envía DELETE /api/mocks/<slug> con el token de administrador en una cabecera Bearer. En la práctica un ttl_seconds corto es más fiable, porque la expiración también recoge tras los trabajos que fallan o se cancelan antes de llegar a su paso de limpieza.
¿Puedo usar la API desde un lenguaje que no sea Go?
Sí. Es HTTP y JSON corrientes, así que sirve cualquier cliente: la CLI es solo una comodidad para shells y Makefiles, y nada en la API depende de ella. La referencia de la API lista todos los endpoints con un ejemplo de curl listo para ejecutar.

Construye el tuyo propio

Crear un mock

Guías relacionadas

← Todas las guías

Última actualización: 2026-10-17