Validateur de spécification OpenAPI / Swagger
Guide
Validateur de spécification OpenAPI / Swagger
Validez instantanément vos spécifications OpenAPI 3.0, 3.1 ou Swagger 2.0. Collez du YAML ou du JSON, obtenez une liste structurée d'erreurs et d'avertissements avec des chemins JSON Pointer, et formatez joliment votre spécification pour une documentation claire.
Comment utiliser
Collez votre spécification OpenAPI ou Swagger dans le champ d'entrée. Le validateur détecte automatiquement s'il s'agit de YAML ou de JSON et la version de la spécification que vous utilisez. Les résultats affichent un résumé des points d'accès, des schémas, des erreurs et des avertissements. Chaque problème comprend un chemin JSON Pointer afin que vous puissiez localiser rapidement le problème.
Caractéristiques
- Support Multi-Version – Valide les spécifications Swagger 2.0, OpenAPI 3.0.x et OpenAPI 3.1.x
- Validation Structurelle – Vérifie les champs requis (info, paths, version), les types corrects et la structure du schéma
- Validation Sémantique – Détecte les operationIds dupliqués, les méthodes HTTP invalides, les références $ref brisées et les incohérences de paramètres de chemin
- Chemins d'Erreur – Chaque problème inclut un chemin JSON Pointer pour une localisation précise
- Formatage Soigné – Reformatez votre spécification en JSON ou YAML propre avec une indentation appropriée
- Résumé de la Spécification – Aperçu instantané : version, nombre total de points d'accès, schémas, erreurs et avertissements
- 100% Client-Side – Vos spécifications d'API ne quittent jamais votre navigateur
FAQ
-
Quelle est la différence entre Swagger 2.0 et OpenAPI 3.0 ?
Swagger 2.0 était le format original de spécification d'API développé par SmartBear. Lorsque la spécification a été donnée à l'OpenAPI Initiative en 2015, elle a été renommée OpenAPI. La version 3.0 a introduit des améliorations significatives, notamment un meilleur support pour les rappels, les liens, les serveurs multiples et une structure de composants plus propre. Les deux formats ne sont pas directement compatibles.
-
Pourquoi les operationIds doivent-ils être uniques dans une spécification OpenAPI ?
Les operationIds servent d'identifiants uniques pour chaque opération d'API. Les générateurs de code les utilisent pour créer des noms de méthodes dans les SDK clients, les outils de documentation les utilisent pour les liens d'ancrage et les frameworks de test les utilisent pour référencer des points d'accès spécifiques. Les operationIds dupliqués provoquent des conflits dans tous ces outils en aval.
-
Qu'est-ce qu'un JSON Pointer et comment lire les chemins d'erreurs de validation ?
Un JSON Pointer (RFC 6901) est une syntaxe de chaîne pour identifier une valeur spécifique dans un document JSON. Par exemple, /paths/~1users/get/parameters/0 pointe vers le premier paramètre de l'opération GET /users. Le ~1 échappe une barre oblique dans le segment de chemin. La lecture de ces pointeurs vous indique exactement où dans votre spécification se produit l'erreur de validation.
-
Dois-je écrire ma spécification OpenAPI en YAML ou en JSON ?
Les deux formats sont entièrement pris en charge et fonctionnellement équivalents. YAML est généralement préféré pour les spécifications écrites à la main car il est plus lisible et prend en charge les commentaires. JSON est préférable pour les spécifications générées par machine et la manipulation programmatique. La plupart des outils acceptent l'un ou l'autre format, alors choisissez celui que votre équipe trouve le plus facile à maintenir.
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 21 mars 2026
Impliquez-vous
Aidez-nous à continuer à fournir des outils gratuits et précieux
