Points clés
- Catégorie
- Development
- Types d’entrée
- textarea, select, text, checkbox
- Type de sortie
- json
- Couverture des échantillons
- 4
- API disponible
- Yes
Vue d’ensemble
Ce détecteur de rupture OpenAPI et GraphQL compare deux versions de vos schémas d'API pour identifier instantanément les changements incompatibles (breaking changes). Conçu pour les équipes de développement, il analyse vos spécifications, signale les champs supprimés ou les nouveaux paramètres obligatoires, et génère un rapport d'impact détaillé pour sécuriser vos mises en production.
Quand l’utiliser
- •Avant de fusionner une pull request modifiant le contrat d'une API publique ou interne.
- •Lors de la mise à jour de la documentation OpenAPI pour s'assurer qu'aucune régression n'a été introduite.
- •Pour auditer l'évolution d'un schéma GraphQL et prévenir les équipes clientes des changements à venir.
Comment ça marche
- •Collez la version précédente de votre schéma OpenAPI (YAML/JSON) ou GraphQL SDL dans le champ 'Schéma précédent'.
- •Insérez la nouvelle version mise à jour dans le champ 'Nouveau schéma'.
- •Sélectionnez le type de schéma (OpenAPI ou GraphQL) et activez l'analyse d'impact si nécessaire.
- •L'outil compare les deux contrats et génère un rapport JSON listant les ruptures de compatibilité et le niveau de risque.
Cas d’usage
Exemples
1. Détecter un champ de réponse supprimé avant la mise en production
Développeur Backend- Contexte
- L'équipe a refactorisé un endpoint utilisateur et modifié la structure de la base de données.
- Problème
- S'assurer qu'aucun champ utilisé par le front-end n'a été accidentellement retiré de la réponse de l'API.
- Comment l’utiliser
- Collez l'ancien YAML OpenAPI et le nouveau YAML, puis lancez l'analyse avec l'option d'impact activée.
- Configuration d’exemple
-
Type de schéma : OpenAPI, Inclure l'analyse d'impact : Oui - Résultat
- Le rapport JSON signale un risque 'high' et identifie précisément la suppression du champ 'email' dans la réponse 200 de 'GET /users/{id}'.
2. Examiner un changement de contrat d'entrée GraphQL
Architecte API- Contexte
- Une nouvelle fonctionnalité nécessite d'ajouter une catégorie lors de la création d'un article via GraphQL.
- Problème
- Vérifier si l'ajout de ce nouveau champ d'entrée va casser les mutations existantes des clients.
- Comment l’utiliser
- Insérez l'ancien SDL GraphQL et le nouveau SDL contenant le champ 'category: String!'.
- Configuration d’exemple
-
Type de schéma : GraphQL, Inclure l'analyse d'impact : Oui - Résultat
- L'outil détecte un 'breaking change' car un champ obligatoire a été ajouté, avertissant que les clients doivent mettre à jour leurs requêtes.
Tester avec des échantillons
developmentHubs associés
FAQ
Quels formats de schémas sont supportés ?
L'outil prend en charge les spécifications OpenAPI (Swagger) au format YAML ou JSON, ainsi que les schémas GraphQL (SDL).
Qu'est-ce qu'un 'breaking change' (changement incompatible) ?
Il s'agit d'une modification qui risque de casser le code des clients existants, comme la suppression d'un champ de réponse ou l'ajout d'un paramètre requis.
L'outil peut-il détecter le type de schéma automatiquement ?
Oui, en laissant l'option 'Type de schéma' sur 'Auto detect', l'outil identifiera automatiquement s'il s'agit d'OpenAPI ou de GraphQL.
Que contient le rapport d'impact ?
Le rapport JSON inclut le niveau de risque global, un résumé des modifications, et le détail de chaque changement avec son chemin exact et son impact sur les clients.
Mes schémas d'API sont-ils stockés ?
Non, l'analyse est effectuée localement ou à la volée. Vos contrats d'API ne sont pas conservés.