PK Systems PK Systems
Ferramentas para devs

Gerador de JSON Schema a partir de JSON

Cole uma amostra JSON, receba um JSON Schema (Draft 2020-12 ou Draft 7) com formatos auto-detectados e lista de campos obrigatórios.

Gerador de JSON Schema a partir de JSON

Saída

O schema aparece aqui enquanto você digita.

O que é JSON Schema?

JSON Schema é um vocabulário para descrever JSON. Ele diz "este objeto deve ter estas chaves, destes tipos, com valores que casam com estes padrões" — e validadores (Ajv, jsonschema, opis/json-schema, toda ferramenta OpenAPI) impõem o contrato. O padrão atual é o Draft 2020-12, usado pelo OpenAPI 3.1; Draft 7 é a versão anterior e ainda comum em toolchains mais antigas. As duas têm diferenças sintáticas pequenas — este gerador emite ambas.

Como usar

Cole uma amostra JSON. O painel de saída emite um schema correspondente com cada folha tipada como string, integer, number, boolean, null, mais object / array para containers. Com Detectar formatos, strings que casam com padrões comuns recebem hint formatemail, uri, date, date-time, uuid, ipv4. Com Marcar required, toda chave presente na amostra é adicionada em required — coloque um array de múltiplos objetos para conseguir uma lista honesta de obrigatórios (só sobrevivem chaves presentes em todos os objetos). Os campos opcionais Title e $id são adicionados no topo do schema.

Formatos detectados

  • email — qualquer coisa que case com o padrão simples local@host.tld.
  • uri — strings começando com http:// ou https://.
  • dateYYYY-MM-DD (full-date RFC 3339).
  • date-timeYYYY-MM-DDTHH:MM:SS[.fff][Z|+HH:MM] (RFC 3339).
  • timeHH:MM:SS[.fff][Z|+HH:MM].
  • uuid — UUIDs RFC 4122 v1–v5.
  • ipv4 — endereços IPv4 em decimal pontuado.
Outros formatos da spec (uri-reference, idn-email, regex, json-pointer) não são auto-detectados; adicione na mão se precisar.

Perguntas frequentes

Posso confiar num schema inferido em produção?
Trate como ponto de partida. O inferrer só vê o que está na sua amostra — se um campo é integer positivo em todos os exemplos mas a documentação permite zero ou negativos, o schema inferido fica apertado demais. Da mesma forma, campos que aparecem em 100% das amostras podem ser opcionais na realidade. Sempre revise o schema contra o contrato documentado da sua API antes de subir.
Como ele decide os campos required?
Para um único objeto, toda chave fica required (porque toda chave está presente). Para um array de objetos, só chaves presentes em todos os objetos ficam required — chaves em alguns mas não em todos viram opcionais. Bate com como validadores leem o schema: "este campo deve sempre estar presente".
Qual a diferença entre Draft 2020-12 e Draft 7?
Para 95% dos schemas, nenhuma — o vocabulário básico é idêntico. Diferenças aparecem em features avançadas: $dynamicRef substitui $recursiveRef, items substitui additionalItems em validação de tupla, e algumas keywords mudaram de vocabulário. Se você integra com OpenAPI 3.1 ou Ajv 8+, escolha 2020-12; para Ajv mais velho (v6), Stoplight antigo, ou qualquer coisa gerada pré-2019, escolha Draft 7.
Por que minha data é detectada como date-time em vez de date?
A ordem de detecção é date-time antes de date, então 2024-01-15T00:00:00Z casa com date-time primeiro. 2024-01-15 sozinho casa com date. Se você quer um campo só de data que por acaso inclui hora, edite o schema na mão ou retire o componente de tempo da amostra antes.
O schema preserva campos enum-like?
Não — inferir "isto deve ser um de [active, paused, archived]" exige mais amostras do que um paste típico contém, e falsos positivos são perigosos (um único tenant flipando para um estado novo quebraria validação em produção). Adicione enum: [...] na mão depois de revisar seu domínio.
Posso usar a saída com OpenAPI?
Sim — solte o corpo do schema (tudo menos $schema e $id) numa entrada components.schemas.MyType. OpenAPI 3.1 suporta o vocabulário Draft 2020-12 completo; OpenAPI 3.0 suporta um subconjunto próximo do Draft 7 mas com peculiaridades (sem keyword nullable no Draft 7 — OpenAPI 3.0 adicionou a sua).