Anúncios incomodam? Ir Sem anúncios Hoje 

Conversor de OpenAPI v2 para v3

DadosDesenvolvedor

ANUNCIADO Remover?

ENTRADA

Processo Automático

SAÍDA

Lado cliente

ANUNCIADO Remover?

Guia

Conversor de OpenAPI v2 para v3

Cole uma especificação Swagger 2.0 e obtenha uma versão válida do OpenAPI 3.0.3 de volta, em JSON ou YAML. O conversor aplica as regras oficiais de mapeamento estrutural — movendo definitions under components/schemas, colapsando host, basePathe, e schemes em servers, dividindo consumes e produces em mapeamentos por operação content e reorganizando parâmetros de formulário e definições de segurança — para que sua especificação funcione com as ferramentas modernas do OpenAPI.

Como usar

Cole sua especificação Swagger 2.0 no campo de entrada. JSON e YAML são ambos aceitos; o formato é detectado automaticamente.
Escolha um formato de saída: mantenha o formato de entrada ou force JSON ou YAML.
Deixe Corrigir campos obrigatórios faltantes para preencher automaticamente campos obrigatórios da versão 3, como info.title, info.version, e descrições de respostas faltantes quando a fonte da versão 2 as omitir.
Leia o resumo da conversão e quaisquer avisos exibidos acima do resultado, depois copie ou baixe a especificação OpenAPI 3.0.3 resultante.

Características

Entrada em JSON e YAML, saída em JSON ou YAML — escolha o formato que preferir ou reflita o formato de entrada.
Mapeamento estrutural — definitions → components/schemas, securityDefinitions → components/securitySchemes, parameters/responses são levantados sob components, e cada $ref é reescrito para corresponder.
Servidores a partir de host, basePath e esquemas — combinados em um array da versão 3 servers , com HTTPS preferido quando múltiplos esquemas são listados.
Negociação de conteúdo — consumes e produces são traduzidas para mapeamentos por operação requestBody.content e responses[*].content .
Parâmetros de corpo e de formulário — in: body passa a ser um campo v3 requestBodye, e in: formData os campos são agrupados em um multipart/form-data ou application/x-www-form-urlencoded esquema de corpo da requisição.
Atualização do fluxo de segurança — os valores OAuth2 flow são reorganizados no objeto v3 flows ()implicit, password, clientCredentials, authorizationCode).
Modo de correção — quando habilitado, preenche campos obrigatórios faltantes para que a saída passe em um validador v3, em vez de falhar por defeitos menores na fonte.
Resumo da conversão e avisos — contagem de rotas, esquemas e fluxos de segurança convertidos, além de avisos para qualquer coisa que não pôde ser mapeada de forma um-para-um.
Executa totalmente no navegador — sua especificação nunca sai da página.

 Perguntas frequentes

O que mudou estruturalmente entre Swagger 2.0 e OpenAPI 3.0?

O OpenAPI 3.0 reorganizou peças reutilizáveis sob um único components objeto: definitions tornou-se components/schemas, parameters tornou-se components/parameters, responses tornou-se components/responsese, e securityDefinitions tornou-se components/securitySchemes. A superfície de transporte também mudou: host, basePathe, e schemes foram mescladas em um servers array de URLs base completas, enquanto os arrays implícitos consumes e produces foram substituídos por mapeamentos explícitos content chaveados por tipo de mídia em cada corpo da requisição e resposta.
Por que os corpos de requisição precisaram de uma nova estrutura no OpenAPI 3.0?

No Swagger 2.0, um corpo de requisição era apenas outro parâmetro com in: body, e os campos de formulário eram parâmetros com in: formData. Isso colapsou duas preocupações diferentes (parâmetros de caminho, de consulta e de cabeçalho versus o corpo da requisição) em uma única lista e tornou a negociação de conteúdo difícil. O OpenAPI 3.0 as separou: os parâmetros são apenas para caminho, consulta, cabeçalho e cookie; o corpo da requisição passa a ser um mapa no nível superior requestBody com um content . Isso permite descrever um único ponto de extremidade que aceita application/json, multipart/form-datae, e application/x-www-form-urlencoded com esquemas diferentes para cada um.
Os Swagger 2.0 e OpenAPI 3.0 são compatíveis em nível de protocolo?

Não. São versões de formato de descrição, não versões de protocolo de API, então uma especificação convertida não altera como seu serviço responde em tempo real — mas as ferramentas (geradores, validadores, servidores de mock, visualizadores de UI) devem entender a versão que você publica. O OpenAPI 3.0 introduziu recursos que não têm equivalente na versão 2, incluindo oneOf/anyOf/not, callbacks, links e fluxos de segurança mais ricos. A conversão para frente (v3 → v2) é, portanto, perdedora em geral, enquanto a conversão para trás (v2 → v3) é principalmente mecânica porque a versão 2 é um subconjunto rígido da expressividade do OpenAPI 3.0.
O que significa resolução neste contexto? $ref é um ponteiro de referência JSON, como

A $ref . A conversão precisa reescrever cada ponteiro porque o caminho-alvo muda: #/definitions/User, e assim por diante. Os ponteiros próprios não são resolvidos (o documento ainda referencia por localização), mas devem ser reescritos de forma sincronizada com a mudança estrutural para que a especificação v3 resultante permaneça internamente consistente. #/definitions/User torna-se #/components/schemas/User, #/parameters/AuthHeader torna-se #/components/parameters/AuthHeaderCole sua especificação Swagger 2.0 aqui (YAML ou JSON)...