Datos clave
- Categoría
- Development
- Tipos de entrada
- textarea, select, text, checkbox
- Tipo de salida
- json
- Cobertura de muestras
- 4
- API disponible
- Yes
Resumen
Herramienta que compara versiones de esquemas OpenAPI y GraphQL para detectar automáticamente cambios incompatibles antes del despliegue. Analiza diferencias entre la definición anterior y la nueva, clasifica el nivel de riesgo de publicación y genera un informe estructurado con el impacto específico sobre los consumidores de la API.
Cuándo usarlo
- •Antes de desplegar una nueva versión de API para validar que no se eliminen campos de respuesta ni se agreguen parámetros obligatorios sin documentar.
- •Durante revisiones de código en pull requests que modifican contratos de API, para identificar automáticamente rupturas contractuales.
- •Al auditar compatibilidad hacia atrás entre versiones legacy y nuevas especificaciones durante migraciones de formato.
Cómo funciona
- •Pega el contenido del esquema anterior (YAML, JSON o SDL GraphQL) en el campo "Schema anterior" y la versión actualizada en "Schema nuevo".
- •Selecciona el tipo de esquema (OpenAPI, GraphQL o detección automática) y activa la opción de análisis de impacto para obtener detalles de severidad.
- •El motor compara estructuras semánticas, identifica cambios incompatibles como campos eliminados o inputs requeridos nuevos, y calcula el riesgo de liberación.
- •Recibe un informe JSON con el resumen de cambios, áreas impactadas y clasificación de riesgo como alto, medio o bajo.
Casos de uso
Ejemplos
1. Prevención de breaking change en endpoint de usuarios
Ingeniero de plataforma- Contexto
- El equipo eliminó el campo email de la respuesta 200 del endpoint GET /users/{id} sin versionar la API, lo que podría causar errores en aplicaciones móviles existentes.
- Problema
- Detectar si la eliminación de propiedades en respuestas HTTP constituye un cambio incompatible antes del despliegue a producción.
- Cómo usarlo
- Pegar el esquema OpenAPI anterior en "Schema anterior", la versión modificada en "Schema nuevo", seleccionar "OpenAPI" como tipo y activar "Incluir análisis de impacto".
- Resultado
- El informe JSON indica "releaseRisk": "high", identifica el cambio "Response field removed" en la ruta GET /users/{id}, y alerta sobre la ruptura de contrato al eliminar el campo email.
2. Validación de cambios en input GraphQL
Desarrollador backend- Contexto
- Se requiere agregar un campo obligatorio "category" al input CreatePostInput en el esquema GraphQL de producción para clasificar nuevas publicaciones.
- Problema
- Confirmar si agregar un campo requerido a un objeto de entrada GraphQL genera un breaking change para las mutaciones existentes.
- Cómo usarlo
- Ingresar el SDL GraphQL anterior y el nuevo en los campos de texto correspondientes, seleccionar tipo "GraphQL" y ejecutar la comparación.
- Resultado
- El resultado clasifica el cambio como "breaking" en el área "field", especificando que las mutaciones deben incluir el nuevo campo category obligatorio para evitar errores de validación.
Probar con muestras
developmentHubs relacionados
Preguntas frecuentes
¿Qué formatos de esquema soporta la herramienta?
OpenAPI (Swagger) 2.0 y 3.0 en YAML o JSON, además de GraphQL Schema Definition Language (SDL).
¿Cómo identifica los cambios incompatibles?
Compara campos de respuesta, parámetros de entrada, tipos y requisitos de obligatoriedad entre ambas versiones para detectar eliminaciones o nuevas restricciones.
¿Qué significa el "riesgo de publicación" en el resultado?
Indica la probabilidad de que los cambios generen errores en clientes existentes: "high" cuando existen cambios breaking confirmados que rompen la compatibilidad.
¿Es posible comparar sin especificar el tipo de esquema?
Sí, seleccionando "Auto detect" el sistema identifica automáticamente si el contenido corresponde a OpenAPI o GraphQL.
¿El informe detalla el impacto específico por cambio?
Sí, cuando se activa el análisis de impacto, cada cambio incompatible incluye una descripción del efecto sobre consumidores, como mutaciones que requieren nuevos campos obligatorios.