Validateur Swagger 2.0

Collez une définition Swagger 2.0, en JSON ou en YAML, pour vérifier qu’elle contient le champ de version swagger, un objet info avec un titre et une version, et un objet paths. Les entrées de chemin sont examinées pour détecter une barre oblique initiale manquante et des clés qui ne sont pas des opérations standard.

Comment contrôler un fichier Swagger 2.0

  1. 1

    Copiez votre définition

    Copiez le `swagger.json` ou le `swagger.yaml` complet, en commençant par la ligne `swagger: "2.0"`.

  2. 2

    Collez-la

    Collez-la dans le champ du document OpenAPI / Swagger.

  3. 3

    Lancez le contrôle

    Passez à l'étape des résultats pour obtenir les erreurs et les avertissements.

  4. 4

    Mettez à jour et vérifiez à nouveau

    Appliquez les corrections dans votre fichier et collez la nouvelle version jusqu'à ce que le rapport soit propre.

Ce qui compte comme réussite pour un Swagger 2.0

Pour un fichier 2.0, le contrôle de version est satisfait par une clé swagger de premier niveau. L’outil ne vérifie pas que sa valeur est "2.0", il ne détectera donc pas un mauvais numéro. Au-delà de la version, il exige info.title, info.version et un objet paths.

Les champs propres à Swagger 2.0, comme host, basePath, schemes, definitions et securityDefinitions, ne sont pas examinés. Un host manquant ou un bloc definitions cassé ne seront pas signalés.

Un exemple concret

{
  "swagger": "2.0",
  "info": { "title": "Shop API", "version": "1.0" },
  "paths": {
    "/products": {
      "get": { "summary": "List products" },
      "x-internal": true
    }
  }
}

Le champ de version, info et paths sont tous présents, il n’y a donc aucune erreur. Le rapport affiche un avertissement :

Constat Type Raison
Méthode inconnue ‘x-internal’ sur /products. Avertissement La clé n’est ni une opération standard ni un champ d’élément de chemin

Le document reste jugé valide, car les avertissements ne bloquent pas la validité. Les clés d’extension propres aux éditeurs, comme x-internal, sont légales dans Swagger 2.0 : vous pouvez les laisser en place.

Migrer depuis la 2.0

Si vous prévoyez de passer à OpenAPI 3.x, vous pouvez coller le fichier converti dans la même zone et comparer les résultats. Le contrôle est identique, avec le champ openapi à la place de swagger. Pour la migration proprement dite, utilisez un convertisseur et un linter complets, car cet outil ne traduit pas les paramètres definitions ni host.

Quand un contrôle rapide suffit

Les définitions Swagger 2.0 restent souvent des années dans les dépôts et sont modifiées à la main. Un contrôle structurel rapide est utile lorsque vous héritez d’une définition, lorsqu’un outil refuse de la charger et que vous soupçonnez un champ manquant, ou lorsque vous fusionnez deux fichiers et voulez vous assurer que le résultat conserve ses sections info et paths. Pour les règles complètes de la 2.0, y compris definitions et les paramètres de sécurité, complétez avec un linter dédié.

Gardez à l’esprit qu’un rapport propre ne porte que sur la structure. Les opérations sans réponses, les types de paramètres erronés et les références non résolues sortent du périmètre de ce contrôle : testez aussi le fichier dans votre outil de documentation ou de génération de code.

Questions fréquentes

Non. Il vérifie que le champ swagger ou openapi existe, pas ce qu’il contient.

Non. Seuls le champ de version, l’objet info, l’objet paths et les entrées sous chaque chemin sont contrôlés.

Oui. Le texte est lu d’abord comme JSON, puis comme YAML en cas d’échec. Conservez l’indentation telle quelle au moment du collage.

Les champs parameters, summary, description et servers au niveau du chemin figurent dans la liste des clés acceptées : ils ne déclenchent donc pas l’avertissement de méthode inconnue.

Outils similaires

Outil disponible dans d’autres langues

Guides et cas d'usage