Zusammen mit der X API v2 haben wir eine neue Versionierungsstrategie eingeführt, die es Entwicklern ermöglicht, besser zu verstehen, wann mit Änderungen an den öffentlichen APIs von X zu rechnen ist und wann eine Migration auf neue Versionen erforderlich ist.
Entwickler werden über Abkündigungen, Außerdienststellungen, Änderungen und Erweiterungen der X API über unsere Kommunikationskanäle informiert, damit sie diese Änderungen in ihrer Entwicklungsroadmap angemessen berücksichtigen können. Alle Änderungen an der API werden im Changelog dokumentiert.
Die X API liegt derzeit in drei unterschiedlichen Versionen vor. Wir empfehlen Nutzern nachdrücklich, bei der Planung ihrer Integration die X API v2 zu verwenden, es sei denn, die für Ihren Anwendungsfall erforderliche Funktionalität wurde in v2 noch nicht bereitgestellt.
Weitere Informationen zu den einzelnen Versionen finden Sie auf den folgenden Seiten:
- X API v2
- Gnip 2.0 (Enterprise)
Versionsstrategie
Die Versionierung für die X API wird durch Versionsnummern dargestellt, die im Routenpfad unserer endpoints angegeben sind:
https://api.x.com/2/tweets
Wir beabsichtigen, Hauptversionen der X API bei Bedarf zu veröffentlichen, jedoch nicht häufiger als alle 12 Monate. Eine Hauptversion wird veröffentlicht, wenn breaking changes in der API eingeführt werden. Wir werden beim Start einer neuen Hauptversion Migrationsleitfäden veröffentlichen, um Entwickler beim Wechsel auf die neue Version zu unterstützen.
Ein breaking change erfordert, dass Entwickler ihren Code ändern, um die bestehende Funktionalität in ihrer App beizubehalten. Nicht breaking changes sind additive Änderungen und werden bei Verfügbarkeit in die aktuellste Version ausgerollt, ohne dass auf Entwicklerseite Arbeit erforderlich ist, es sei denn, Sie möchten die neue Funktionalität nutzen.
Wenn ein breaking change mitten im Zyklus ausgerollt werden muss (aus Sicherheits- oder Datenschutzgründen), wird diese Änderung in der aktuellsten Version vorgenommen.
Breaking Changes
Diese Änderungen erfordern, dass Entwickler ihren Code anpassen, um die bestehende Funktionalität ihrer Anwendung beizubehalten.
- Hinzufügen eines neuen erforderlichen Parameters
- Entfernen eines bestehenden endpoint
- Entfernen eines Feldes in der Antwort (obligatorisch oder optional)
- Entfernen eines query-Parameters
- Umstrukturierung des Ein- oder Ausgabeformats (zum Beispiel das Verschieben eines Top-Level-Felds in ein Unterfeld oder das Verlegen der Fehlerausgabe auf inline)
- Ändern des Namens oder des Datentyps eines bestehenden Eingabeparameters oder Ausgabewerts
- Ändern des Namens eines Felds
- Ändern des Ressourcennamens
- Ändern eines Antwortcodes
- Ändern von Fehlertypen
- Änderungen an bestehenden Autorisierungsbereichen
Rückwärtskompatible Änderungen
- Hinzufügen eines neuen endpoint
- Hinzufügen eines neuen optionalen Parameters
- Hinzufügen eines neuen Antwortfelds
- Änderung von Texten in Fehlermeldungen
- Verfügbarkeit neuer Scopes
- „Nullen“ von fields (Setzen des Werts eines Felds auf null aus Datenschutz-/Sicherheitsgründen als Alternative zur vollständigen Entfernung)
Veraltung und Einstellung
Zunächst unsere Definition, was Veraltung und Einstellung für die X API bedeuten:
- Veraltung (Deprecation): Die Funktion wird vom Team nicht mehr aktiv unterstützt. Es wird keine neue Funktionalität für diese Funktion veröffentlicht, und bei Fehlern oder Problemen ist die Wahrscheinlichkeit, dass wir eine Behebung vornehmen, äußerst gering.
- Einstellung (Retired): Die Funktion ist nicht mehr zugänglich.
In den meisten Fällen wird, sobald eine neue Version veröffentlicht ist, die vorherige Version als veraltet markiert. Versionen verbleiben für einen bestimmten Zeitraum im Status „veraltet“, danach werden sie eingestellt.
Bitte bleiben Sie informiert, um mehr über zukünftige Veraltungen und Einstellungen zu erfahren.