¿Qué es un mock JSON y por qué importa?
Un mock JSON es una respuesta simulada que imita lo que devolvería una API real. Es la diferencia entre estar bloqueado esperando a que el backend implemente el endpoint o poder avanzar con el frontend hoy. También sirve para tests automatizados estables: los mocks no fallan por timeouts ni por la base de datos.
Estructura de una respuesta lista
La forma más común para colecciones es {"data": [...], "meta": {...}}.
El array data contiene los items; meta trae paginación, total y
timestamps. Esta separación deja espacio para crecer (links HATEOAS, errores parciales)
sin romper a los clientes existentes.
Paginación, total y links
Tres campos que siempre conviene incluir: page, limit y
total. Con eso, el cliente sabe cuántas páginas vienen y puede pintar un
paginador. Si tu API es cursor-based, devolvé next_cursor en lugar de página.
Errores con forma estándar
El estándar más usado es Problem Details (RFC 7807):
{"type": "...", "title": "...", "status": 422, "detail": "...", "errors": [...]}.
Tener una forma única para todos los errores simplifica el manejo en el cliente: una sola
función parsea cualquier respuesta de error.
Servir el mock
- json-server: levanta un REST completo a partir de un JSON. Útil para prototipos.
- MSW (Mock Service Worker): intercepta fetch en el browser. Ideal para frontend.
- Postman mock servers: hosted, comparte URL con el equipo.
- Vite/webpack dev server: archivos en
/publiccon respuestas estáticas.
Datos realistas
Evitá "foo" y "bar". Usá nombres, emails y direcciones plausibles
(Faker, Mockaroo). El frontend descubre bugs cuando los strings son largos, los números
negativos o los timestamps cruzan zonas horarias. Datos planos esconden esos casos.
Mock vs contract testing
Los mocks pueden divergir de la API real si nadie los actualiza. Para evitarlo, usá contract testing (Pact, OpenAPI schema validation): el mock se valida contra el contrato y el backend también. Si alguien rompe el contrato, los tests fallan.
Casos de error que olvidamos
El mock más común es 200 OK feliz. Pero el frontend también necesita probar 401, 403, 422 con errores de validación, 429 con rate limit, 500 con error genérico y 503 con mantenimiento. Tener mocks para cada caso te obliga a manejarlos.