Zusammenfassung

  • RFC 9745 vom März 2025 definiert Deprecation mit einem Datum nach Structured Fields. Der Hinweis verändert die Funktion der Ressource zunächst nicht.
  • Ein Link mit der Relation deprecation kann zu Richtlinien oder einer Migrationsanleitung führen, bevor ein Datum gesetzt wird. RFC 8594 von 2019 definiert Sunset für den erwarteten Zeitpunkt, zu dem eine Ressource nicht mehr antwortet.
  • Der Header bezieht sich zunächst auf die Ressource der Antwort. Ein größerer Geltungsbereich braucht veröffentlichte API-Regeln; datierte Antwortmitschnitte würden tatsächliche Einführung belegen.

Der Erfolg kommt mit einer Warnung

Das Ende einer Schnittstelle beginnt häufig mit erfolgreichen Antworten. Die Überwachung meldet Verfügbarkeit, Daten fließen, Nutzer haben keinen akuten Anlass zur Beschwerde. Der Betreiber bereitet dennoch einen Ersatz vor und möchte neue Integrationen fernhalten. Eine Mitteilung allein auf einer Dokumentationsseite erreicht den Entwickler beim Blick auf den Verkehr nicht zwingend. Eine Warnung erst beim Ausfall lässt ihm keine Zeit für Umbau und Tests.

RFC 9745 fügte den Hinweis in die HTTP-Antwort ein. Das Feld Deprecation benennt den Zeitpunkt, zu dem die mit der Antwort identifizierte Ressource abgekündigt wird oder wurde. Sein Wert ist ein Date-Item nach Structured Fields. Das Beispiel Deprecation: @1688169599 entspricht dem 30. Juni 2023 um 23:59:59 Uhr UTC. Ein zukünftiger Wert kündigt die Abkündigung an, ein vergangener datiert sie rückblickend.

Die Ressource kann bei beiden Werten weiterarbeiten. Der Standard hält ausdrücklich fest, dass die Abkündigung das Verhalten selbst nicht ändert. Eine einzige Antwort liefert also ein gültiges Ergebnis und eine Warnung für künftige Architekturentscheidungen. Für die Clientseite ist das kein bloßes Etikett. Jeder neue Aufrufer, der sich jetzt anbindet, vergrößert die spätere Umzugsarbeit.

Der Geltungsbereich muss nachvollziehbar sein. Das Feld beschreibt zuerst die Ressource, deren Antwort es trägt. Soll eine ganze API oder eine Gruppe von Endpunkten erfasst werden, muss der Anbieter Regeln für diese Ausweitung definieren. Eine einzelne beobachtete Antwort verrät etwas über ihren eigenen Kontext; den größeren Plan erklärt der Betreiber.

Die Anleitung darf vor dem Termin erscheinen

RFC 9745 registrierte auch die Link-Relation deprecation. Über Link kann der Server auf Richtlinien, Ersatzwege und Migrationshinweise verweisen. Solch ein Verweis kann bereits auftauchen, wenn das Datumsfeld noch fehlt. Entwickler erfahren dann, wie ein Anbieter künftig abkündigen will, während die Ressource selbst noch nicht abgekündigt ist.

Ein Datum baut keine Anwendung um. Ein Clientteam muss Antworten vergleichen, Berechtigungen klären, Daten übertragen, Tests schreiben und eine neue Version veröffentlichen. Die verlinkte Anleitung kann diese Fragen aus der laufenden API heraus erreichbar machen. Ihr Inhalt liegt in der Hand des Anbieters, die Umsetzung beim Kunden. Die Standardisierung verschickt die Nachricht zuverlässig; die Arbeitsstunden bleiben ungleich verteilt.

Abkündigung und Abschaltung haben verschiedene Uhren

RFC 8594 vom Mai 2019 führte Sunset für den Zeitpunkt ein, an dem eine Ressource voraussichtlich nicht mehr antwortet. Der Wert ist ein HTTP-Datum. Deprecation markiert dagegen den Moment, in dem weitere Abhängigkeit unerwünscht wird, obwohl der Dienst noch läuft. Die beiden Felder beantworten verschiedene Planungsfragen: Wann sollte niemand Neues mehr darauf bauen? Wann könnte die Antwort ausbleiben?

RFC 9745 erlaubt beide Felder und verlangt, dass Sunset nicht vor Deprecation liegt. Sein Beispiel nennt den 30. Juni 2023 für die Abkündigung und den 30. Juni 2024 für das erwartete Ende. Die umgekehrte Reihenfolge würde einen Dienst vor seiner Abkündigung schließen. Auch die Syntax verrät zwei Entstehungsgeschichten: Das neue Feld verwendet das Datum mit @ aus Structured Fields, Sunset das ältere HTTP-Datumsformat.

Der Nutzen solcher Termine hängt an einer klar beschriebenen Reichweite, einem funktionierenden Ersatz und einem Betreiber, der seine Planung ernst nimmt. Für Aussagen über tatsächliche Einführung fehlen datierte Antworten benannter Dienste. Der RFC zeigt bereits die neue Möglichkeit: Eine laufende API kann ihren Nutzern im erfolgreichen Antwortstrom mitteilen, dass ihre Zukunft anderswo liegt.