Archivos de ejemplo y mocks de API

Tres cosas que se piden todos los días

JSON con tu estructura

Defines los campos y su tipo —texto, número, booleano, fecha, correo, UUID, nombre, DNI…— y obtienes un array de objetos con la cantidad que pidas. Sirve para sembrar una base de datos, alimentar un mock server o rellenar un contrato de API antes de que exista el backend.

Respuestas HTTP mock

Los códigos que de verdad se prueban: 200, 400, 401, 404 y 500, con cabeceras verosímiles y un cuerpo editable. Se copian como respuesta cruda o como bloque de documentación, listos para pegar en un README o en la definición de tu API.

Códigos de barras y QR

EAN-13 con el dígito verificador correcto y prefijo de país a elegir, Code128 para cualquier texto, y QR. Todos se descargan en PNG o en SVG, así que valen igual para una prueba en pantalla o para imprimir una etiqueta.

Qué código HTTP devolver en cada caso

Elegir bien el código es la mitad del diseño de una API, y es donde más se improvisa. Estos son los cinco que genera la herramienta y cuándo corresponde cada uno:

La herramienta genera cada respuesta con cabeceras verosímiles y un cuerpo editable, en dos formatos: como respuesta cruda —para pegar en un mock server— o como bloque de documentación, listo para el README o la especificación de tu API.

El dígito verificador del EAN-13

Un código de barras EAN-13 no es un número cualquiera: los tres primeros dígitos son el prefijo de país que asigna GS1 —775 es el de Perú, 84 España, 80 Italia— y el último es un verificador de módulo 10 con pesos alternos 1 y 3:

function dvEan13(doce) {
  let suma = 0;
  for (let i = 0; i < 12; i++) suma += Number(doce[i]) * (i % 2 ? 3 : 1);
  return String((10 - (suma % 10)) % 10);
}
dvEan13("775123456789")   // el 13.º dígito

Cualquier lector de código de barras comprueba ese dígito antes de aceptar la lectura, así que un EAN-13 con el verificador mal ni siquiera llega a tu aplicación: lo rechaza el escáner. Por eso los que genera esta herramienta lo llevan correcto: para que la prueba llegue de verdad a tu código.

JSON de ejemplo que aguanta una revisión

Un JSON de prueba con "nombre": "test1" y "email": "a@a.com" sirve para que compile, no para probar nada. En cuanto alguien mira los datos, o en cuanto una pantalla los pinta, se nota que son de mentira: las columnas quedan raras, los nombres no ocupan lo que ocupan de verdad y nadie detecta que el diseño se rompe con un apellido largo.

Por eso el generador de JSON permite definir el tipo de cada campo y rellenarlo con datos coherentes: un DNI que es un DNI, un correo con estructura de correo, un nombre peruano de longitud realista. Defines los campos una vez, eliges cuántos registros y lo exportas.

Para qué se usa

• Sembrar una base de datos de desarrollo o de pruebas sin copiar datos reales de producción, que es una práctica arriesgada y en muchos casos ilegal.
• Alimentar un mock server mientras el backend todavía no existe, para que el equipo de front no espere.
• Documentar un contrato de API con ejemplos que se parecen a lo que va a llegar de verdad.
• Probar el rendimiento de una tabla con cien registros en lugar de tres, que es cuando aparecen los problemas de paginación y de orden.