Convertisseur OpenAPI v2 vers v3
Guide
Convertisseur OpenAPI v2 vers v3
Collez une spécification Swagger 2.0 et obtenez une version valide de OpenAPI 3.0.3 sous forme de JSON ou YAML. Le convertisseur applique les règles officielles de correspondance structurale — déplaçant definitions sous components/schemas, regroupant host, basePathet schemes dans servers, divisant consumes et produces en cartes par opération content et reformulant les paramètres de formulaire et les définitions de sécurité — afin que votre spécification soit compatible avec les outils modernes d'OpenAPI.
Comment utiliser
- Collez votre spécification Swagger 2.0 dans la zone d'entrée. JSON et YAML sont tous deux acceptés ; le format est détecté automatiquement.
- Choisissez un format de sortie : conservez le format d'entrée ou forcez le JSON ou YAML.
- Quitter Corriger les champs manquants pour compléter automatiquement les champs obligatoires de la version 3 comme
info.title,info.version, et les descriptions des réponses manquantes lorsque la source v2 les omet. - Lisez le résumé de conversion et les avertissements affichés au-dessus du résultat, puis copiez ou téléchargez la spécification OpenAPI 3.0.3 résultante.
Caractéristiques
- Entrée en JSON ou YAML, sortie en JSON ou YAML — choisissez le format que vous préférez ou répétez celui d'entrée.
- Correspondance structurale —
definitions→components/schemas,securityDefinitions→components/securitySchemes,parameters/responsessont déplacées souscomponents, et chaque$refpointeur est réécrit pour correspondre. - Serveurs à partir de host, basePath, schemes — combinés dans le tableau v3
serversavec HTTPS préféré lorsque plusieurs schémas sont listés. - Négociation de contenu —
consumesetproducessont traduites en cartes par opérationrequestBody.contentetresponses[*].content. - Paramètres de corps et de formulaire —
in: bodydevient un champ v3requestBodyetin: formDatales champs sont regroupés dans unmultipart/form-dataouapplication/x-www-form-urlencodedschéma de corps de requête. - Mise à jour du flux de sécurité — les valeurs OAuth2
flowsont réattribuées à l'objet v3flows()implicit,password,clientCredentials,authorizationCode). - Mode de correction — lorsque activé, remplit les champs manquants afin que la sortie passe un validateur v3 au lieu de échouer à cause de défauts mineurs dans la source.
- Résumé de conversion et avertissements — comptage des chemins, des schémas et des schémas de sécurité convertis, ainsi que des avertissements pour tout ce qui ne peut pas être mappé de manière univoque.
- Fonctionne entièrement dans votre navigateur — votre spécification ne quitte jamais la page.
FAQ
-
Quelles sont les modifications structurales entre Swagger 2.0 et OpenAPI 3.0 ?
OpenAPI 3.0 a réorganisé les composants réutilisables sous un seul
componentsobjet :definitionsest devenucomponents/schemas,parametersest devenucomponents/parameters,responsesest devenucomponents/responsesetsecurityDefinitionsest devenucomponents/securitySchemes. La surface de transport a également changé :host,basePathetschemesont été fusionnées dans unserverstableau de URL de base complètes, tandis que les tableaux implicitesconsumesetproducesont été remplacés par descontenttableaux clés par type de média sur chaque corps de requête et réponse. -
Pourquoi les corps de requête ont-ils besoin d'une nouvelle forme dans OpenAPI 3.0 ?
Dans Swagger 2.0, un corps de requête était simplement un paramètre avec
in: body, et les champs de formulaire étaient des paramètres avecin: formData. Cela a fusionné deux préoccupations différentes (paramètres de chemin/paramètres de requête/paramètres d'en-tête versus le corps de requête) dans une même liste et a rendu la négociation de type de contenu difficile. OpenAPI 3.0 les a séparées : les paramètres sont uniquement pour chemin, requête, en-tête et cookie ; le corps de requête est déplacé dans unrequestBodyavec uncontentmap. Cela vous permet de décrire une seule endpoint qui accepteapplication/json,multipart/form-dataetapplication/x-www-form-urlencodedavec des schémas différents pour chaque. -
Swagger 2.0 et OpenAPI 3.0 sont-ils compatibles en transmission ?
Non. Ils sont des versions de format de description, pas des versions de protocole d'API, donc une spécification convertie ne change pas la manière dont votre service réagit en temps réel — mais les outils (générateurs, validateurs, serveurs de simulation, afficheurs UI) doivent comprendre la version que vous publiez. OpenAPI 3.0 a introduit des fonctionnalités sans équivalent dans v2, notamment
oneOf/anyOf/not, les callbacks, les liens et des flux de sécurité plus riches. Le passage vers l'avant (v3 → v2) est donc perdu en général, tandis que le passage en arrière (v2 → v3) est largement mécanique car v2 est un sous-ensemble strict de l'expressivité de v3. -
Qu'est-ce que
$refsignifie en ce contexte ?UN
$refest un pointeur de référence JSON comme#/definitions/User. La conversion doit réécrire chaque pointeur car le chemin cible change :#/definitions/Userdevient#/components/schemas/User,#/parameters/AuthHeaderdevient#/components/parameters/AuthHeader, et ainsi de suite. Les pointeurs eux-mêmes ne sont pas résolus (le document continue à faire référence par emplacement), mais ils doivent être réécrits en corrélation avec le déplacement structuré afin que la spécification v3 résultante reste internement cohérente.
Installez nos extensions
Ajoutez des outils IO à votre navigateur préféré pour un accès instantané et une recherche plus rapide
恵 Le Tableau de Bord Est Arrivé !
Tableau de Bord est une façon amusante de suivre vos jeux, toutes les données sont stockées dans votre navigateur. D'autres fonctionnalités arrivent bientôt !
Outils essentiels
Tout voir Nouveautés
Tout voirMise à jour: Notre dernier outil a été ajouté le 18 juin 2026
