Generador de JSON Schema desde JSON

¿Qué es JSON Schema?

JSON Schema es un vocabulario para describir JSON. Dice "este objeto debe tener estas llaves, de estos tipos, con valores que coincidan con estos patrones" — y los validadores (Ajv, jsonschema, opis/json-schema, toda herramienta OpenAPI) imponen el contrato. El estándar actual es Draft 2020-12, que es lo que usa OpenAPI 3.1; Draft 7 es la versión anterior y aún común en toolchains más viejas. Las dos tienen diferencias sintácticas menores — este generador emite ambas.

Cómo usar

Pega una muestra JSON. El panel de salida emite un schema correspondiente con cada hoja tipada como string, integer, number, boolean, null, más object / array para contenedores. Con Detectar formatos, las strings que coinciden con patrones comunes reciben hint format — email, uri, date, date-time, uuid, ipv4. Con Marcar required, cada llave presente en la muestra se añade a required — suelta un array de múltiples objetos para conseguir una lista honesta de requeridos (solo sobreviven llaves presentes en todos los objetos). Los campos opcionales Title y $id se añaden arriba del schema.

Formatos detectados

email — cualquier cosa que coincida con el patrón simple local@host.tld.
uri — strings que empiezan con http:// o https://.
date — YYYY-MM-DD (full-date RFC 3339).
date-time — YYYY-MM-DDTHH:MM:SS[.fff][Z|+HH:MM] (RFC 3339).
time — HH:MM:SS[.fff][Z|+HH:MM].
uuid — UUIDs RFC 4122 v1–v5.
ipv4 — direcciones IPv4 en decimal punteado.

Otros formatos de la spec (uri-reference, idn-email, regex, json-pointer) no se auto-detectan; añádelos a mano si los necesitas.

Preguntas frecuentes

¿Puedo confiar en un schema inferido en producción?

Trátalo como punto de partida. El inferrer solo ve lo que está en tu muestra — si un campo es integer positivo en cada ejemplo pero está documentado para permitir cero o negativos, el schema inferido queda demasiado apretado. De igual forma, campos que aparecen en 100% de tus muestras pueden ser opcionales en realidad. Siempre revisa el schema contra el contrato documentado de tu API antes de subir.

¿Cómo elige los campos required?

Para un objeto único, cada llave queda required (porque cada llave está presente). Para un array de objetos, solo las llaves presentes en cada objeto quedan required — las llaves en algunos pero no en todos se vuelven opcionales. Coincide con cómo los validadores leen el schema: "este campo debe estar siempre presente".

¿Cuál es la diferencia entre Draft 2020-12 y Draft 7?

Para 95% de los schemas, ninguna — el vocabulario básico es idéntico. Las diferencias aparecen en features avanzadas: $dynamicRef reemplaza a $recursiveRef, items reemplaza a additionalItems en validación de tupla, y unas keywords se movieron entre vocabularios. Si integras con OpenAPI 3.1 o Ajv 8+, elige 2020-12; para Ajv viejo (v6), Stoplight antiguo, o cualquier cosa generada antes de 2019, elige Draft 7.

¿Por qué mi fecha se detecta como date-time y no date?

El orden de detección es date-time antes de date, así que 2024-01-15T00:00:00Z coincide con date-time primero. 2024-01-15 solo coincide con date. Si quieres un campo solo de fecha que casualmente incluye hora, edita el schema a mano o quita el componente de tiempo de tu muestra primero.

¿El schema preserva campos tipo enum?

No — inferir "esto debe ser uno de [active, paused, archived]" requiere más muestras de las que un paste típico contiene, y los falsos positivos son peligrosos (un solo tenant cambiando a un estado nuevo rompería la validación en producción). Añade enum: [...] a mano una vez que hayas revisado tu dominio.

¿Puedo usar la salida con OpenAPI?

Sí — suelta el cuerpo del schema (todo menos $schema y $id) en una entrada components.schemas.MyType. OpenAPI 3.1 soporta el vocabulario Draft 2020-12 completo; OpenAPI 3.0 soporta un subconjunto cercano al Draft 7 pero con un par de peculiaridades (sin keyword nullable en Draft 7 — OpenAPI 3.0 añadió la suya).

Generador de JSON Schema desde JSON