Wichtige Fakten
- Kategorie
- Development
- Eingabetypen
- textarea, select, text, checkbox
- Ausgabetyp
- json
- Sample-Abdeckung
- 4
- API verfügbar
- Yes
Überblick
Der OpenAPI-Diff-Breaking-Change-Detektor vergleicht zwei Versionen von OpenAPI- oder GraphQL-Schemas und identifiziert automatisch Breaking Changes. Das Tool analysiert strukturelle Unterschiede, bewertet das Release-Risiko und generiert einen detaillierten Impact-Bericht, der API-Teams hilft, rückwärtsinkompatible Änderungen vor dem Deployment zu erkennen und Konsumenten frühzeitig zu informieren.
Wann verwenden
- •Vor dem Deployment neuer API-Versionen, um rückwärtsinkompatible Änderungen zu identifizieren
- •Beim Review von Pull Requests, die Schema-Änderungen enthalten
- •Zur Kommunikation von API-Änderungen an Frontend- und Mobile-Teams
So funktioniert es
- •Fügen Sie das vorherige Schema in das Feld 'Altes Schema' und die aktualisierte Version in 'Neues Schema' ein (YAML oder JSON für OpenAPI, SDL für GraphQL).
- •Wählen Sie den Schema-Typ (OpenAPI/Swagger oder GraphQL) oder nutzen Sie die automatische Erkennung.
- •Das Tool vergleicht die Strukturen, erkennt entfernte Felder, neue Pflichtfelder und Typänderungen.
- •Sie erhalten einen JSON-Bericht mit Risikobewertung, Anzahl der Breaking Changes und betroffenen Bereichen.
Anwendungsfälle
Beispiele
1. Entferntes Antwortfeld vor dem Release erkennen
- Hintergrund
- Ein Backend-Team aktualisiert den User-Endpunkt und entfernt das Feld 'email' aus der 200-Antwort, ohne die Mobile-Clients zu informieren.
- Problem
- Das fehlende Feld würde bestehende Mobile-Apps zum Absturz bringen, die 'email' für die Benutzeranzeige erwarten.
- Verwendung
- Fügen Sie das alte OpenAPI-Schema in 'Altes Schema' und die aktualisierte Version in 'Neues Schema' ein. Aktivieren Sie die Impactanalyse, um das Risiko zu bewerten.
- Ergebnis
- Der Bericht markiert das entfernte Feld als Breaking Change mit hohem Risiko und zeigt den genauen Pfad 'GET /users/{id} -> response 200.email', sodass das Team die Änderung vor dem Deployment korrigieren kann.
2. Neues Pflichtfeld in GraphQL-Mutation identifizieren
- Hintergrund
- Das Schema-Team fügt dem CreatePostInput eine Kategorie hinzu, um Beiträge zu klassifizieren, und macht das Feld zur Pflichtangabe.
- Problem
- Alle bestehenden Mutations-Aufrufe ohne das neue 'category'-Feld schlagen fehl, was Frontend- und Mobile-Teams betrifft.
- Verwendung
- Geben Sie beide GraphQL-Schema-Versionen (SDL) in die Textfelder ein. Der Detektor erkennt automatisch oder durch manuelle Auswahl den GraphQL-Typ.
- Ergebnis
- Der JSON-Bericht klassifiziert die Änderung als Breaking Change im Bereich 'field' und warnt, dass alle Clients das neue Pflichtfeld in Mutations senden müssen.
Mit Samples testen
developmentVerwandte Hubs
FAQ
Was versteht das Tool unter einem Breaking Change?
Breaking Changes sind Schema-Änderungen, die bestehende Client-Integrationen zerstören, wie das Entfernen von Antwortfeldern, das Hinzufügen neuer Pflichtfelder in Inputs oder das Ändern von Feldtypen.
Welche Schema-Formate werden unterstützt?
OpenAPI 3.x und Swagger 2.0 in YAML oder JSON sowie GraphQL Schema Definition Language (SDL).
Wie funktioniert die automatische Schema-Erkennung?
Das Tool analysiert die Struktur der Eingabe, um anhand typischer Schlüsselwörter und Syntax zwischen OpenAPI- und GraphQL-Schemas zu unterscheiden.
Was enthält die Impactanalyse?
Die Analyse bewertet das Release-Risiko (hoch/mittel/niedrig), listet betroffene Pfade und Endpunkte auf und beschreibt die konkreten Auswirkungen auf API-Konsumenten.
Kann ich YAML mit JSON vergleichen?
Ja, das Tool normalisiert beide Formate intern, sodass Sie problemlos ein YAML-Schema mit einer JSON-Version vergleichen können.