01
Identifier la version
Les règles viennent du champ openapi ou swagger. En 3.1, un document contenant uniquement components peut être valide même si la liste des endpoints est vide.
- L’exemple inclut un paramètre partagé et un modèle récursif.
Outils API
Validateur OpenAPIrelire le contrat
Collez une spécification JSON ou YAML, explorez ses opérations et examinez les diagnostics avant export.
Validateur OpenAPI
Source OpenAPI
Résultat
Aucun endpoint de requête correspondant.
0 éléments sur 0
La spécification reste dans ce navigateur. Aucun appel API ni récupération de référence distante.
Options de sortie
Vérifie la structure et les règles usuelles des chemins. L’export couvre paths, sans webhooks ni callbacks. Les exemples et réponses réelles ne sont pas testés.
500 000 caractères · profondeur 60 · 50 000 nœuds · 100 diagnostics · délai de validation de 5 secondes.
Collez une spécification ou chargez un exemple.
Copie et téléchargement suivent la vue sélectionnée. L’export des endpoints comprend toute la liste, indépendamment de la recherche.
Le Validateur OpenAPI facilite la relecture d’un contrat généré. Un document peut être lisible tout en omettant la description d’une réponse ou la déclaration d’un paramètre de chemin. Les opérations permettent de replacer chaque erreur dans son contexte.
Le champ de version choisit les règles. Changer la sérialisation JSON ou YAML ne transforme pas un ancien contrat Swagger en OpenAPI 3 et ne teste pas le service déployé.
Pourquoi utiliser ce Validateur OpenAPI ?
Relier les définitions aux opérations qui les utilisent.
Lire les paramètres réellement appliqués
Le Validateur OpenAPI regroupe les opérations par chemin de requête. Dépliez une entrée pour voir les paramètres hérités, les corps, les réponses et les déclarations de sécurité. La recherche réduit l’affichage, tandis que l’export conserve toutes les opérations.
Repérer les dépendances non vérifiées
Les références locales sont recherchées dans le document fourni. Une cible absente produit une erreur. Les liens de modèles récursifs sont conservés, et les références externes restent signalées comme non vérifiées.
Trois vérifications utiles avant le partage
02
Comparer les paramètres hérités
L’opération remplace un paramètre de chemin qui porte le même nom au même emplacement. Vérifiez le résultat fusionné plutôt que de compter les déclarations brutes.
- Désactivez la validation automatique pour exécuter avec Ctrl/Cmd + Enter.
03
Exporter la bonne représentation
La spécification formatée convient à la poursuite de l’édition. Endpoints produit l’inventaire JSON complet ; Markdown produit une documentation des opérations.
- Toute modification de la source ou des options invalide l’ancien résultat.
Vérifier la structure et documenter les opérations
Des schémas adaptés aux versions
L’éditeur OpenAPI utilise de vrais schémas de document pour Swagger 2.0, OpenAPI 3.0 et 3.1. Il vérifie aussi la forme des mots-clés JSON Schema 2020-12 standards dans les modèles 3.1.
Cohérence des chemins
Les identifiants d’opération répétés, paramètres dupliqués et paramètres de chemin non déclarés ou non obligatoires sont diagnostiqués. Les métadonnées servers et parameters ne sont pas comptées comme opérations HTTP.
Conversion JSON et YAML
Choisissez deux ou quatre espaces. La conversion garde les valeurs, les références et le champ de version ; elle n’effectue aucune migration des modèles ou des paramètres de corps.
Documentation Markdown
L’export rassemble les métadonnées API, serveurs, paramètres, corps et réponses. Les descriptions sont échappées et les blocs de code correctement délimités. Aucun HTML de la spécification n’est exécuté dans la vue.
Portée et limites du résultat
- Un document autonome
- Versions prises en charge : Swagger 2.0 et OpenAPI 3.0.x/3.1.x. La version 3.2 et les autres familles sont rejetées. Une référence locale désigne une partie de ce document, pas un fichier voisin sur votre disque.
- Références externes et dialectes
- Aucune URL ni aucun fichier relatif n’est récupéré. Les identifiants de ressources, ancres, références dynamiques et dialectes personnalisés entraînent un avertissement de vérification incomplète. Regroupez les dépendances dans un environnement de confiance.
- La présentation YAML est reconstruite
- Les commentaires et styles de guillemets ne sont pas conservés. Utilisez un seul document YAML 1.2 avec clés textuelles, sans ancres, alias, fusions ni balises personnalisées. Les clés dupliquées et nombres impossibles à représenter exactement sont refusés.
- Inventaire des requêtes uniquement
- Les opérations sous paths sont exportées. Webhooks et callbacks sont vérifiés structurellement, mais exclus de l’inventaire et de ses contrôles sémantiques. Exemples, réponses réelles, authentification et règles métier demandent des tests séparés.
- Des limites explicites
- L’entrée accepte 500 000 caractères, une profondeur de 60 et 50 000 nœuds. Le traitement s’arrête au-delà de 100 diagnostics, de 2 000 000 caractères de résultat ou de cinq secondes. Découpez les gros contrats pour les examiner.
Questions sur le Validateur OpenAPI
Quelles versions sont prises en charge ?
Swagger 2.0 et OpenAPI 3.0.x/3.1.x, en JSON ou YAML. Le champ racine sélectionne la version ; une version non prise en charge est refusée plutôt que traitée selon d’autres règles.
Quels résultats peut-on exporter ?
La vue sélectionnée fournit une spécification JSON/YAML, un inventaire JSON complet ou une documentation Markdown. La recherche ne réduit pas l’inventaire exporté. Les erreurs et résultats périmés désactivent l’export.
Quelle différence y a-t-il entre OpenAPI et Swagger ?
Swagger 2.0 est une ancienne version de la spécification ; les versions 3.x portent le nom OpenAPI. Swagger désigne aussi une famille d’outils. Ici, chaque version possède ses propres règles de validation.
Peut-on convertir une spécification YAML en JSON ?
Oui, et l’inverse aussi. Choisissez le format de sortie indépendamment de l’entrée. La version et les valeurs restent identiques, mais les commentaires YAML et choix de présentation ne sont pas préservés.
Comment les références $ref sont-elles traitées ?
Les JSON Pointer internes sont vérifiés sans développer indéfiniment les modèles récursifs. Les paramètres partagés sont résolus pour leur affichage. Les fichiers externes, ancres et portées avancées sont signalés comme non vérifiés.
Un résultat inattendu avec votre document ?
Relire la prochaine spécification
Utilisez le Validateur OpenAPI pour corriger les diagnostics, puis exporter la représentation adaptée à votre équipe.
Le formatage conserve la version du contrat.