Revisar uma definição OpenAPI e referências locais

Cole a definição para revisar problemas de edição. Este linter limitado não certifica conformidade completa nem testa o comportamento de uma API em execução.

Funciona localmente no seu navegador
OpenAPI definition

Cole uma definição OpenAPI 3.0 ou 3.1 em JSON/YAML. Ela permanece no navegador e nunca é buscada nem enviada.

What this checks
  • LOCAL Análise de JSON ou YAML sem requisição de rede.
  • STRUCTURE OpenAPI version, info, caminhos, operações e objetos de resposta.
  • REFERENCES Local #/... references and missing path parameter declarations.

Este é um linter voltado à edição; não substitui uma suíte completa de conformidade do esquema nem testes de contrato contra uma API ativa.

Validation report
  • Valide um documento OpenAPI para ver um relatório local.

Como validar uma definição OpenAPI

Cada constatação traz uma gravidade e um JSON Pointer do elemento a que pertence, então um problema pode ser rastreado até o ponto exato da definição.

  1. Cole a definição ou clique em Carregar exemplo para começar de um documento 3.1 já preenchido.
  2. Clique em Validar definição. O cabeçalho conta as operações encontradas e o número de erros, avisos e notas.
  3. Leia a lista de constatações: cada entrada mostra o nível, o JSON Pointer do elemento afetado e uma frase descrevendo o que está errado.
  4. Clique em Limpar para esvaziar a caixa e o relatório.

O que o validador verifica

Problemas relatados como erros

A ausência da string de versão openapi, do objeto info e do objeto paths são erros, e dentro de info são exigidos title e version. Uma chave de rota que não começa com / é um erro, assim como uma operação cujo objeto responses está vazio, porque quem consome a API precisa de ao menos um código de resposta ou default.

Um template de rota como /orders/{id} precisa declarar {id} com in: path e required: true, já que sem isso um cliente não consegue montar a chamada. Referências escritas como #/components/... são resolvidas, e uma que não leva a lugar nenhum é relatada como erro no próprio ponteiro.

Avisos e notas

Uma operação sem operationId é um aviso, porque clientes gerados o usam como nome de método. Também são avisos um requestBody sem mapa content, uma referência que aponta para outro arquivo ou URL e um documento com swagger: "2.0". Uma definição sem o array servers é uma nota: os consumidores usam a URL padrão do OpenAPI.

Uma string de versão presente mas que não é 3.x, como "3" ou "4.0.0", é relatada como aviso e não como erro, de modo que uma definição quase correta ainda gera um relatório completo.

Como ler o relatório

O símbolo ~1 em um ponteiro representa uma barra dentro de uma rota, então /paths/~1orders~1{id}/get é GET /orders/{id}. Todas as constatações de uma execução aparecem juntas, então um documento com vários problemas não precisa ser validado repetidas vezes.

webhooks e components.pathItems são permitidos pelo OpenAPI 3.1 e não são contados como operações. Um objeto paths vazio é válido e passa.

O que o validador não decide

Apenas a estrutura e as referências locais são verificadas. Esquemas de segurança, convenções de tags, estilo de nomes e se o desenho da API faz sentido ficam de fora, e nada é consultado em um servidor ao vivo. Duas operações que compartilham o mesmo operationId não são relatadas.

Dentro de dados de exemplo — o conteúdo de example, o valor de uma entrada examples, um enum ou um const — a chave $ref é tratada como dado e não como referência, então um payload que a contenha por acaso não gera um erro falso.

Ferramentas recentes: