Validador de Swagger 2.0

Pega una definición Swagger 2.0, en JSON o YAML, para comprobar que tiene el campo de versión swagger, un objeto info con título y versión, y un objeto paths. Las entradas de ruta se revisan para ver si tienen barra inicial y si contienen claves que no son operaciones estándar.

Cómo comprobar un archivo Swagger 2.0

  1. 1

    Copia tu definición

    Copia el `swagger.json` o `swagger.yaml` completo, empezando por la línea `swagger: "2.0"`.

  2. 2

    Pégala

    Pégala en el campo del documento OpenAPI / Swagger.

  3. 3

    Ejecuta la comprobación

    Continúa al paso de resultados para obtener los errores y los avisos.

  4. 4

    Actualiza y vuelve a comprobar

    Aplica las correcciones en tu archivo y pega la nueva versión hasta que el informe esté limpio.

Qué cuenta como correcto en un Swagger 2.0

En un archivo 2.0, la comprobación de versión se cumple con una clave swagger de nivel superior. La herramienta no verifica que su valor sea "2.0", así que no detectará un número incorrecto. Más allá de la versión, necesita info.title, info.version y un objeto paths.

Los campos propios de Swagger 2.0, como host, basePath, schemes, definitions y securityDefinitions, no se examinan. Un host que falte o un bloque definitions roto no se informarán.

Un ejemplo práctico

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

El campo de versión, info y paths están todos, así que no hay errores. El informe muestra un aviso:

Hallazgo Tipo Motivo
Método desconocido ‘x-internal’ en /products. Aviso La clave no es una operación estándar ni un campo de elemento de ruta

El documento sigue considerándose válido, porque los avisos no bloquean la validez. Las claves de extensión de proveedor como x-internal son legales en Swagger 2.0, así que puedes dejarla tal cual.

Migrar desde la 2.0

Si planeas pasar a OpenAPI 3.x, puedes pegar el archivo convertido en el mismo cuadro y comparar los resultados. La comprobación es la misma, con el campo openapi en lugar de swagger. Para la migración real usa un conversor y un linter completos, porque esta herramienta no traduce la configuración de definitions ni de host.

Cuándo basta una comprobación rápida

Las definiciones Swagger 2.0 suelen vivir años en los repositorios y se editan a mano. Una comprobación estructural rápida es útil cuando heredas una, cuando una herramienta se niega a cargarla y sospechas que falta un campo, o cuando fusionas dos archivos y quieres asegurarte de que el resultado conserva sus secciones info y paths. Para las reglas completas de la 2.0, incluidas definitions y la configuración de seguridad, usa después un linter específico.

Ten en cuenta que un informe limpio es una afirmación solo sobre la estructura. Las operaciones sin respuestas, los tipos de parámetro incorrectos y las referencias sin resolver quedan fuera de esta comprobación, así que prueba también el archivo en tu herramienta de documentación o de generación de código.

Preguntas frecuentes

No. Comprueba que exista el campo swagger u openapi, no lo que contiene.

No. Solo se comprueban el campo de versión, el objeto info, el objeto paths y las entradas bajo cada ruta.

Sí. El texto se lee primero como JSON y, si falla, como YAML. Mantén la indentación sin cambios al pegar.

Los parameters, summary, description y servers a nivel de ruta están en la lista de claves aceptadas, así que no activan el aviso de método desconocido.

Herramientas relacionadas

Herramienta disponible en otros idiomas

Guías y casos de uso