Fatos principais
- Categoria
- Development
- Tipos de entrada
- textarea, select, text, checkbox
- Tipo de saída
- json
- Cobertura de amostras
- 4
- API disponível
- Yes
Visão geral
O Detector de quebra em diff OpenAPI é uma ferramenta essencial para equipes de desenvolvimento que precisam comparar schemas OpenAPI ou GraphQL antes de realizar deploys. Ele analisa as versões antiga e nova da sua API, identifica automaticamente alterações que quebram a compatibilidade (breaking changes) e gera um relatório detalhado de impacto, garantindo integrações mais seguras e previsíveis.
Quando usar
- •Antes de aprovar pull requests que alteram contratos de API para evitar quebras em clientes existentes.
- •Durante o planejamento de novas versões de APIs GraphQL ou REST para avaliar o impacto de novos campos obrigatórios.
- •Ao auditar mudanças em documentações OpenAPI/Swagger para garantir que nenhuma rota ou parâmetro foi removido acidentalmente.
Como funciona
- •Cole o schema antigo (OpenAPI YAML/JSON ou GraphQL SDL) no campo 'Schema antigo'.
- •Insira a versão atualizada do contrato no campo 'Novo schema'.
- •Selecione o tipo de schema (OpenAPI ou GraphQL) ou deixe em detecção automática e marque a opção de análise de impacto.
- •A ferramenta processará as diferenças e retornará um relatório JSON destacando o risco da release e as breaking changes encontradas.
Casos de uso
Exemplos
1. Prevenção de quebra por remoção de campo na resposta
Desenvolvedor Backend- Contexto
- A equipe de backend refatorou o endpoint de listagem de usuários e removeu o campo de email da resposta padrão.
- Problema
- Garantir que a remoção do campo não passe despercebida e quebre o aplicativo frontend que depende desse dado.
- Como usar
- Cole o YAML original no 'Schema antigo' e o YAML refatorado no 'Novo schema', selecionando o tipo 'OpenAPI'.
- Configuração de exemplo
-
{"schemaType": "openapi", "includeImpactAnalysis": true} - Resultado
- O relatório JSON sinaliza um risco de release 'high' e aponta a remoção do campo 'email' na resposta 200 do endpoint GET /users/{id}.
2. Validação de nova mutation no GraphQL
Arquiteto de API- Contexto
- Um novo requisito de negócio exige que a criação de posts inclua uma categoria obrigatória.
- Problema
- Identificar se a adição do campo 'category' como obrigatório afetará os clientes atuais.
- Como usar
- Insira o SDL do GraphQL antigo e o novo contendo o input 'CreatePostInput' atualizado.
- Configuração de exemplo
-
{"schemaType": "graphql", "includeImpactAnalysis": true} - Resultado
- A ferramenta detecta a adição de um campo de entrada obrigatório e alerta que mutations existentes precisarão ser atualizadas para enviar o novo campo.
Testar com amostras
developmentHubs relacionados
FAQ
Quais formatos de schema a ferramenta suporta?
A ferramenta suporta especificações OpenAPI (Swagger) em YAML ou JSON, além de schemas GraphQL (SDL).
O que é considerado uma 'breaking change'?
Alterações como remoção de rotas, exclusão de campos de resposta, adição de parâmetros obrigatórios ou mudanças de tipo de dados que quebram a integração de clientes atuais.
Posso desativar a análise de impacto?
Sim, você pode desmarcar a opção 'Incluir análise de impacto' se desejar apenas uma lista simples das diferenças estruturais.
A ferramenta detecta mudanças que não quebram a API?
Sim, o relatório JSON também pode resumir alterações seguras (non-breaking changes), como a adição de campos opcionais ou novas rotas.
Como o risco da release é calculado?
O risco é classificado como 'high' (alto) sempre que uma ou mais breaking changes são detectadas, alertando a equipe sobre possíveis falhas em produção.