¿Odias los anuncios? Ir Sin publicidad Hoy 

Convertidor de OpenAPI v2 a v3

DatosDesarrollador

ANUNCIO · ¿ELIMINAR?

APORTE

Proceso automático

PROD.

Lado cliente

ANUNCIO · ¿ELIMINAR?

Guía

Convertidor de OpenAPI v2 a v3

Pega una especificación Swagger 2.0 y obtén una versión válida de OpenAPI 3.0.3 en formato JSON o YAML. El convertidor aplica las reglas oficiales de mapeo estructural — moviendo definitions debajo components/schemas, agrupando host, basePathy schemes en servers, dividiendo consumes y produces en mapas por operación y reorganizando los parámetros de formulario y las definiciones de seguridad — para que tu especificación funcione con las herramientas modernas de OpenAPI. content Pega tu especificación Swagger 2.0 en el cuadro de entrada. JSON y YAML son ambos aceptados; el formato se detecta automáticamente.

Cómo Usar

Elige un formato de salida: mantener el formato de entrada o forzar JSON o YAML.
Corregir campos faltantes
Deja para rellenar automáticamente campos obligatorios de la versión 3 como , y descripciones de respuestas faltantes cuando el origen de versión 2 las omite. info.title, info.versionLee el resumen de conversión y cualquier advertencia mostrada arriba del resultado, luego copia o descarga la especificación resultante de OpenAPI 3.0.3.
Entrada en JSON y YAML, salida en JSON o YAML

Características

— elige el formato que prefieras o mantén el de entrada. Mapeo estructural
se mueven bajo — definitions → components/schemas, securityDefinitions → components/securitySchemes, parameters/responses , y cada componentsse reescribe para coincidir. $ref Servidores desde host, basePath, esquemas
— combinados en el array de v3, con HTTPS preferido cuando se indican múltiples esquemas. Negociación de contenido servers se traducen en mapas por operación.
Parámetros de cuerpo y de formulario — consumes y produces se convierte en un campo v3 requestBody.content y responses[*].content los campos se agrupan en un esquema de cuerpo de solicitud.
Actualización de flujo de seguridad — in: body — los valores de OAuth2 requestBodyy in: formData se remapean al objeto v3 multipart/form-data o application/x-www-form-urlencoded ()
Modo de corrección — cuando está activado, rellena campos faltantes para que la salida pase un validador de v3 en lugar de fallar por defectos leves en la fuente. flow Resumen de conversión y advertencias flows — cuenta de rutas, esquemas y esquemas de seguridad convertidos, más advertencias para cualquier cosa que no se pueda mapear de forma uno a uno.implicit, password, clientCredentials, authorizationCode).
— tu especificación nunca abandona la página. ¿Qué cambios estructurales hubo entre Swagger 2.0 y OpenAPI 3.0?
OpenAPI 3.0 reorganizó los elementos reutilizables bajo un único objeto:
Funciona completamente en tu navegador se convirtió en

 Preguntas frecuentes

. La superficie de transporte también cambió:

se fusionaron en un components array de URLs base completas, mientras que los arrays implícitos definitions fueron reemplazados por mapas explícitos components/schemas, parameters fueron reemplazados por mapas explícitos components/parameters, responses fueron reemplazados por mapas explícitos components/responsesy securityDefinitions fueron reemplazados por mapas explícitos components/securitySchemesclave por tipo de medio en cada cuerpo de solicitud y respuesta. host, basePathy schemes ¿Por qué se necesitó una nueva forma para los cuerpos de solicitud en OpenAPI 3.0? servers En Swagger 2.0, un cuerpo de solicitud era simplemente otro parámetro con consumes y produces , y los campos de formulario eran parámetros con content . Eso combinaba dos preocupaciones diferentes (parámetros de ruta, consulta, cabecera versus el cuerpo de la solicitud) en una lista y hacía la negociación de contenido incómoda. OpenAPI 3.0 los separó: los parámetros solo se usan para ruta, consulta, cabecera y cookie; el cuerpo de la solicitud se mueve al nivel superior
mapa. Esto te permite describir un único punto de acceso que acepta

con esquemas diferentes para cada uno. in: body¿Son compatibles en red Swagger 2.0 y OpenAPI 3.0? in: formDataNo. Son versiones de formato de descripción, no versiones de protocolo de API, por lo que una especificación convertida no cambia cómo responde tu servicio en tiempo real — pero las herramientas (generadores, validadores, servidores de simulación, visores de interfaz) deben entender la versión que publiques. OpenAPI 3.0 introdujo características que no tienen equivalente en v2, incluyendo requestBody con un content , callbacks, enlaces y flujos de seguridad más ricos. Ir hacia adelante (v3 → v2) es generalmente pérdida de información, mientras que ir hacia atrás (v2 → v3) es en gran medida mecánico porque v2 es un subconjunto estricto de la expresividad de v3. application/json, multipart/form-datay application/x-www-form-urlencoded ¿Qué significa resolución en este contexto?
es un puntero de referencia JSON como

. La conversión debe reescribir cada puntero porque el camino objetivo cambia: oneOf/anyOf/not, y así sucesivamente. Los punteros mismos no se resuelven (el documento sigue referenciando por ubicación), pero deben reescribirse de forma sincronizada con el movimiento estructural para que la especificación resultante de v3 permanezca internamente consistente.
Pega tu especificación Swagger 2.0 aquí (YAML o JSON)... $ref Convertidor de OpenAPI v2 a v3 1

A $ref Convertidor de OpenAPI v2 a v3 #/definitions/UserPega una especificación Swagger 2.0 y obtén una versión válida de OpenAPI 3.0.3 en formato JSON o YAML. El convertidor aplica las reglas oficiales de mapeo estructural #/definitions/User se convierte en #/components/schemas/User, #/parameters/AuthHeader se convierte en #/components/parameters/AuthHeader, y así sucesivamente. Los punteros en sí mismos no se resuelven (el documento sigue haciendo referencia por ubicación), pero deben ser reescritos de forma sincronizada con el movimiento estructural para que la especificación resultante de v3 permanezca internamente consistente.