Comment inspecter une définition AsyncAPI

Collez une définition AsyncAPI en YAML ou JSON : la page liste ses canaux, les opérations qui y sont déclarées, les messages portés par chaque canal, les serveurs et la version du document. La lecture se fait dans le navigateur : la définition n’est jamais envoyée et aucune requête ne quitte la page.

C’est une aide à la lecture d’un fichier de spécification, pas un client de broker ni un validateur. Elle montre ce qui figure réellement dans le texte collé, y compris le cas d’une référence de message pointant vers une définition absente du document.

  1. Collez la définition dans le champ, ou utilisez Charger un exemple pour un petit document AsyncAPI 3.0.
  2. Cliquez sur Analyser localement. Les formes AsyncAPI 2.x et 3.0 sont lues, en YAML comme en JSON.
  3. Lisez le rapport à droite : version, titre, serveurs et une ligne par canal avec ses opérations et ses messages.
  4. Utilisez Copier pour emporter le rapport, Effacer pour vider le champ et le rapport.

Ce que montre le rapport et ce qu’il laisse de côté

Comment les deux versions de la spécification sont lues

En AsyncAPI 3.0, les messages d’un canal se trouvent sous channel.messages, et chaque opération de la section operations nomme son canal, généralement par une $ref. En 2.x, le canal contient publish et subscribe, et chacun porte un message. L’inspecteur lit les deux formes : une ligne 3.0 prend ses messages dans la table messages, une ligne 2.x dans publish.message ou subscribe.message.

Les références de canal sont résolues par nom avec l’échappement JSON Pointer appliqué : une référence comme #/channels/user~1signed-up correspond au canal dont la clé est user/signed-up. Quand un message est une référence plutôt qu’un objet intégré, le nom situé à la fin de la référence remplace une colonne vide.

Ce que contient le rapport

Le rapport est du JSON : il peut être lu ou comparé lors d’une relecture. Il contient la version asyncapi déclarée, le titre et la version de info, les noms des serveurs et, pour chaque canal, les opérations trouvées à côté des noms de messages. En 2.x l’opération vient du canal lui-même, en 3.0 elle est associée par la référence du canal ; un canal sans aucune opération est marqué declared pour que la différence reste visible.

Quatre compteurs figurent sous le rapport : version de la spécification, canaux, opérations et serveurs. En dessous, la page énumère ce qu’elle a remarqué — une définition sans info.title ou sans aucun canal — afin qu’un document vide ou à moitié rempli ne paraisse pas complet.

Ce qu’il ne fait pas

L’inspecteur n’ouvre aucune connexion, ne s’abonne à aucun sujet et ne contacte jamais les serveurs cités dans le document. Le mot local du panneau est littéral : tout est de l’analyse de texte avec le JavaScript déjà chargé dans la page, et c’est aussi pourquoi l’outil fonctionne réseau coupé.

Ce n’est pas non plus un linter AsyncAPI. Il ne vérifie ni la validité des bindings, ni l’existence des schémas référencés, ni le respect de toutes les règles de la spécification. Une définition contenant une erreur qui n’est pas recherchée ici sera annoncée comme lue avec succès. Pour une validation règle par règle, utilisez les outils officiels AsyncAPI et considérez cette page comme une lecture rapide de la structure.

Des limites à connaître

L’analyseur accepte du YAML et du JSON ordinaires. Les clés dupliquées, les ancres et les balises personnalisées au-delà des usuelles sortent du lecteur YAML léger : un document qui en dépend peut ne pas être lu comme le ferait une bibliothèque complète. Un crochet non fermé ou une indentation cassée sont signalés avec le numéro de ligne au lieu d’être devinés.

La taille est traitée dans le navigateur : une très grande définition coûte de la mémoire et du temps sur votre machine, pas sur un serveur. Un document de plusieurs centaines de canaux se lit en deux secondes environ, et la page reste réactive parce que le travail est une seule passe sur le texte analysé.

Outils récents :