Du musst eine Breaking Change an einer öffentlichen API vornehmen. Wie versionierst du sie und wie ziehst du das alte Verhalten zurück?

Prüf zuerst, ob es überhaupt brechen muss: Felder hinzufügen und optionale Parameter akzeptieren ist rückwärtskompatibel, solange Clients unbekannte Felder ignorieren. Wenn es wirklich bricht, versionier explizit, meistens ein Path-Präfix für Major-Versionen, betreib beide Versionen parallel gegen ein internes Modell, veröffentliche einen Deprecation-Zeitplan mit Headern und Metriken pro Version, und entfern die alte erst, wenn der Traffic darauf praktisch null ist.

Mein erster Schritt ist zu prüfen, ob es brechen muss. Ein Feld hinzufügen, einen optionalen Parameter hinzufügen, einen Enum-Wert hinzufügen, falls Clients Unbekanntes tolerieren, das alles geht ohne Version Bump raus. Breaking heißt ein Feld entfernen oder umbenennen, Validierung verschärfen oder die Bedeutung eines bestehenden Werts ändern. Wenn es wirklich bricht, nehme ich eine Major-Version im Pfad, weil sie in Logs sichtbar ist und für Clients leicht nachvollziehbar, und ich behalte die alte Version als dünne Übersetzungsschicht über demselben internen Modell, damit ich nicht zwei Implementierungen pflege. Dann der Teil, der wirklich Zeit kostet: Requests pro Version pro Client instrumentieren, ein Sunset-Datum im Response-Header und in den Docs veröffentlichen und die größten Aufrufer direkt kontaktieren. Beim letzten Mal fiel der Traffic auf v1 auf eine Handvoll Requests pro Tag aus zwei Integrationen, wir haben uns gemeldet, und drei Monate später war das Entfernen sicher. Ohne Metriken pro Client kommst du nie dazu, irgendwas zu löschen.