Revisar una definición OpenAPI y referencias locales

Pega la definición para revisar problemas de edición. Este linter limitado no certifica conformidad completa ni prueba el comportamiento de una API en funcionamiento.

Se ejecuta localmente en tu navegador
OpenAPI definition

Pega una definición OpenAPI 3.0 o 3.1 en JSON/YAML. Permanece en este navegador y nunca se descarga ni se sube.

What this checks
  • LOCAL Análisis de JSON o YAML sin solicitudes de red.
  • STRUCTURE OpenAPI version, info, rutas, operaciones y objetos de respuesta.
  • REFERENCES Local #/... references and missing path parameter declarations.

Es un linter centrado en la edición, no sustituye una suite completa de conformidad del esquema ni las pruebas de contrato contra una API activa.

Validation report
  • Valida un documento OpenAPI para obtener un informe local.

Cómo validar una definición OpenAPI

Cada hallazgo lleva una gravedad y un JSON Pointer del elemento al que pertenece, de modo que un problema se puede rastrear hasta el punto exacto de la definición.

  1. Pega la definición o pulsa Cargar ejemplo para partir de un documento 3.1 ya rellenado.
  2. Pulsa Validar definición. El encabezado cuenta las operaciones encontradas y el número de errores, avisos y notas.
  3. Lee la lista de hallazgos: cada entrada muestra su nivel, el JSON Pointer del elemento afectado y una frase que describe el problema.
  4. Pulsa Limpiar para vaciar el cuadro y el informe.

Qué revisa el validador

Problemas que se notifican como errores

La ausencia de la cadena de versión openapi, del objeto info y del objeto paths son errores, y dentro de info se exigen title y version. Una clave de ruta que no empieza por / es un error, igual que una operación cuyo objeto responses está vacío, porque quien consume la API necesita al menos un código de respuesta o default.

Una plantilla de ruta como /orders/{id} debe declarar {id} con in: path y required: true, ya que sin ella un cliente no puede construir la llamada. Las referencias escritas como #/components/... se resuelven, y una que no lleva a ninguna parte se notifica como error en su propio puntero.

Avisos y notas

Una operación sin operationId es un aviso, porque los clientes generados lo usan como nombre de método. También son avisos un requestBody sin mapa content, una referencia que apunta a otro archivo o URL y un documento con swagger: "2.0". Una definición sin matriz servers es una nota: los consumidores usan la URL predeterminada de OpenAPI.

Una cadena de versión presente pero que no es 3.x, como "3" o "4.0.0", se notifica como aviso y no como error, de modo que una definición casi correcta sigue produciendo un informe completo.

Cómo leer el informe

El símbolo ~1 en un puntero representa una barra dentro de una ruta, así que /paths/~1orders~1{id}/get es GET /orders/{id}. Todos los hallazgos de una ejecución se listan juntos, de modo que un documento con varios problemas no hay que validarlo una y otra vez.

webhooks y components.pathItems están permitidos por OpenAPI 3.1 y no se cuentan como operaciones. Un objeto paths vacío es válido y pasa la revisión.

Qué no decide el validador

Solo se revisan la estructura y las referencias locales. Los esquemas de seguridad, las convenciones de etiquetas, el estilo de nombres y si el diseño de la API es acertado quedan fuera, y no se consulta ningún servidor en vivo. Dos operaciones que comparten el mismo operationId no se notifican.

Dentro de los datos de ejemplo — el contenido de example, el valor de una entrada examples, un enum o un const — la clave $ref se trata como dato y no como referencia, de modo que una carga útil que la contenga por casualidad no genera un error falso.

Herramientas recientes: