Cómo inspeccionar una definición AsyncAPI

Pega una definición AsyncAPI en YAML o JSON y la página lista sus canales, las operaciones declaradas en ellos, los mensajes de cada canal, los servidores y la versión del documento. La lectura ocurre en el navegador: la definición no se sube y ninguna petición sale de la página.

Es una ayuda de lectura para un archivo de especificación, no un cliente de bróker ni un validador. Muestra lo que realmente hay en el texto pegado, incluido el caso de una referencia de mensaje que apunta a una definición ausente del documento.

  1. Pega la definición en el campo o pulsa Cargar ejemplo para un documento AsyncAPI 3.0 pequeño.
  2. Pulsa Analizar localmente. Se leen tanto las formas AsyncAPI 2.x como 3.0, en YAML o en JSON.
  3. Lee el informe de la derecha: versión, título, servidores y una fila por canal con sus operaciones y mensajes.
  4. Usa Copiar para llevarte el informe y Limpiar para vaciar el campo y el informe.

Qué muestra el informe y qué deja fuera

Cómo se leen las dos versiones de la especificación

En AsyncAPI 3.0 los mensajes de un canal están bajo channel.messages, y cada operación de la sección operations nombra su canal, normalmente mediante una $ref. En 2.x el canal contiene publish y subscribe, y cada uno lleva un mensaje. El inspector lee ambas formas: una fila 3.0 toma sus mensajes del mapa messages y una fila 2.x de publish.message o subscribe.message.

Las referencias de canal se resuelven por nombre con el escapado de JSON Pointer aplicado, así que una referencia como #/channels/user~1signed-up coincide con el canal cuya clave es user/signed-up. Cuando un mensaje es una referencia en lugar de un objeto incrustado, se muestra el nombre al final de la referencia en vez de dejar la columna vacía.

Qué contiene el informe

El informe es JSON, así que puede leerse o compararse en una revisión. Incluye la versión declarada de asyncapi, el título y la versión de info, los nombres de los servidores y, por cada canal, las operaciones encontradas junto a los nombres de mensaje. En 2.x la operación sale del propio canal y en 3.0 se asocia por la referencia del canal; un canal sin ninguna operación se marca como declared para que la diferencia siga visible.

Bajo el informe hay cuatro contadores: versión de la especificación, canales, operaciones y servidores. Debajo, la página enumera lo que ha notado —una definición sin info.title o sin ningún canal— para que un documento vacío o a medio llenar no parezca completo.

Qué no hace

El inspector nunca abre una conexión, se suscribe a un tema ni contacta con los servidores nombrados en el documento. La palabra local del panel es literal: todo es análisis de texto con el JavaScript ya cargado en la página, y por eso la herramienta sigue funcionando sin conexión.

Tampoco es un linter de AsyncAPI. No comprueba que los bindings sean válidos, que existan los esquemas referenciados ni que el documento cumpla todas las reglas de la especificación. Una definición con un error que aquí no se busca se dará por leída correctamente. Para la validación regla por regla usa las herramientas oficiales de AsyncAPI y toma esta página como una lectura rápida de la estructura.

Límites que conviene conocer

El analizador acepta YAML y JSON corrientes. Las claves duplicadas, los anclajes y las etiquetas propias más allá de las habituales quedan fuera del lector ligero de YAML, así que un documento que dependa de ellos puede no leerse como lo haría una biblioteca completa. Un corchete sin cerrar o una indentación rota se informan con el número de línea en lugar de adivinarse.

El tamaño se procesa en el navegador, así que una definición muy grande cuesta memoria y tiempo en tu máquina, no en un servidor. Un documento con varios cientos de canales se lee en unos dos segundos y la página sigue respondiendo porque el trabajo es un único recorrido sobre el texto analizado.

Herramientas recientes: