Validador de OpenAPI JSON

Cole o conteúdo do seu openapi.json ou swagger.json e obtenha uma verificação estrutural em segundos. O validador confirma que o JSON é lido, que o campo de versão existe, que info tem título e versão e que paths está presente. Depois, avisa sobre nomes de caminho estranhos e chaves de operação desconhecidas.

Como validar um arquivo JSON do OpenAPI

  1. 1

    Copie o arquivo

    Abra seu `openapi.json` e copie o documento inteiro, da chave de abertura até a de fechamento.

  2. 2

    Cole na caixa

    Cole no campo do documento OpenAPI / Swagger. Não é preciso remover espaços nem reformatar.

  3. 3

    Execute a verificação

    Avance para a etapa de resultados para executar a validação.

  4. 4

    Corrija e repita

    Edite o arquivo para cada erro, cole de novo e execute até o relatório não mostrar erros.

Erros comuns de JSON que fazem a verificação falhar

O JSON é mais rigoroso que o YAML, então a maioria das falhas em um arquivo editado à mão vem da sintaxe, não do desenho da API. As causas mais comuns são uma vírgula sobrando após a última propriedade, aspas simples em vez de duplas, um comentário (o JSON não os aceita) ou uma chave de fechamento faltando depois de um objeto paths longo. Um arquivo quebrado normalmente termina com a mensagem “Não foi possível interpretar como JSON ou YAML”, ou com erros de campos ausentes, porque nada utilizável foi lido.

Se você vir apenas um erro de análise, encontre primeiro o deslize de sintaxe. As verificações estruturais rodam quando o documento é lido como objeto.

Um exemplo prático

Considere este documento pequeno:

{
  "openapi": "3.0.3",
  "info": { "title": "Orders API" },
  "paths": {
    "orders": { "get": { "summary": "List orders" } }
  }
}

Ele é lido, e o campo openapi e o objeto paths estão presentes. O relatório ainda mostraria:

Achado Tipo Motivo
info.version é obrigatório. Erro info tem título, mas não version
O caminho ‘orders’ deve começar com ‘/’. Aviso A chave do caminho não tem barra inicial

Como há um erro, o documento não é reportado como válido. Adicione "version": "1.0.0" em info e renomeie a chave para /orders. Uma segunda execução elimina os dois achados.

O que uma aprovação significa e o que não significa

Um relatório limpo significa que a estrutura básica está correta. Ele não segue links $ref, não verifica schemas nem confirma se toda operação tem respostas. Trate-o como um portão rápido antes de confirmar o arquivo e depois rode um linter completo para regras mais profundas.

Um fluxo prático para especificações JSON

Mantenha a spec em controle de versão e cole-a aqui antes de cada commit que altere paths. Como a verificação é rápida, ela funciona como uma checagem de sanidade depois de mesclar mudanças de várias pessoas, quando chaves duplicadas ou uma chave mal colocada são mais prováveis. Se seu JSON é gerado por um script de build, cole a saída gerada e não o template, para testar o que os leitores realmente receberão. Quando o relatório estiver limpo, compartilhe o arquivo ou entregue-o a um gerador de documentação com mais confiança de que a estrutura de nível superior está sólida.

Perguntas frequentes

Não. Espaços em branco e indentação não importam. Cole o arquivo como está.

O JSON padrão não permite vírgula após o último item de um objeto ou array, então o documento não pode ser lido como JSON. Remova a vírgula e execute a verificação de novo.

Sim. A verificação de versão aceita um campo openapi ou um campo swagger, então arquivos JSON do Swagger 2.0 e do OpenAPI 3.x passam pela mesma verificação estrutural.

Não. Os achados aparecem como mensagens, como um campo ausente ou um nome de caminho, sem números de linha. Procure no arquivo a chave citada na mensagem.

Ferramentas relacionadas

Ferramenta disponível em outros idiomas

Guias e casos de uso