Points clés
- Catégorie
- Développement et Web
- Types d’entrée
- textarea
- Type de sortie
- html
- Couverture des échantillons
- 4
- API disponible
- Yes
Vue d’ensemble
Ce détecteur de breaking changes API compare deux schémas OpenAPI 3.x pour identifier les modifications susceptibles de casser les intégrations clientes. Il génère un rapport détaillé mettant en évidence les suppressions de champs, les durcissements de contrat et propose des stratégies de migration pour sécuriser vos déploiements.
Quand l’utiliser
- •Avant de publier une nouvelle version majeure ou mineure de votre API pour vérifier la rétrocompatibilité.
- •Lors de la revue de code modifiant le contrat d'interface OpenAPI pour anticiper les impacts côté client.
- •Pour planifier la communication technique et rédiger les guides de migration destinés aux développeurs consommateurs de l'API.
Comment ça marche
- •Collez le schéma OpenAPI 3.x de votre version actuelle dans le champ Ancien schéma OpenAPI.
- •Insérez le schéma de la nouvelle version dans le champ Nouveau schéma OpenAPI.
- •L'outil analyse les différences structurelles, comme les champs supprimés ou les paramètres devenus obligatoires.
- •Consultez le rapport HTML généré pour visualiser l'impact des changements et lire les suggestions de migration.
Cas d’usage
Exemples
1. Détection d'un paramètre devenu obligatoire
Développeur Backend- Contexte
- L'équipe ajoute un système de rôles et modifie le endpoint de création d'utilisateur.
- Problème
- S'assurer que les clients actuels ne seront pas bloqués par la nouvelle spécification.
- Comment l’utiliser
- Coller l'ancien schéma sans le champ 'role' et le nouveau schéma où 'role' est requis dans le corps de la requête.
- Configuration d’exemple
-
Ancien schéma avec 'required: false' pour le requestBody, et nouveau schéma avec 'required: true' et 'required: [name, role]'. - Résultat
- L'outil signale un breaking change critique : le corps de la requête est devenu obligatoire et nécessite un nouveau champ 'role'. Il suggère des stratégies d'adaptation.
2. Identification d'un champ de réponse supprimé
Tech Lead API- Contexte
- Une refonte de la base de données entraîne la suppression de certaines données renvoyées par l'API.
- Problème
- Lister exactement quels champs ont disparu pour prévenir les consommateurs de l'API.
- Comment l’utiliser
- Fournir les deux versions du schéma OpenAPI dans les champs texte correspondants.
- Résultat
- Le rapport HTML met en évidence la suppression du champ 'name' dans la réponse 200 et recommande de maintenir le champ déprécié pendant une version avant suppression définitive.
Tester avec des échantillons
developmentFAQ
Quels formats de schémas sont supportés ?
L'outil prend en charge les spécifications au format OpenAPI 3.x, que ce soit en syntaxe YAML ou JSON.
Qu'est-ce qui est considéré comme un breaking change ?
Les modifications telles que la suppression d'un champ de réponse, l'ajout d'un paramètre de requête obligatoire ou le changement de type d'une donnée existante.
L'outil modifie-t-il mes fichiers originaux ?
Non, il effectue uniquement une comparaison en lecture seule des textes fournis et génère un rapport d'analyse.
Puis-je utiliser cet outil pour des API REST classiques ?
Oui, à condition que votre API soit documentée avec une spécification OpenAPI 3.x valide.
Comment les résultats sont-ils présentés ?
Les résultats sont affichés sous forme de rapport HTML, regroupant les changements par niveau d'impact avec des conseils de migration associés.