Twitter konkretisiert API-Einschränkungen

Twitter hat offiziell erläutert, wie es seine API in der kommenden Version 1.1 einschränken will – die erwartet schlechten Nachrichten insbesondere für Entwickler von Third-Party-Clients. [...]

Der für Twitter als Product Director verantwortliche Michael Sippey erläutert die geplanten Änderungen in Version 1.1 der Twitter-API in einem reichlich verklausulierten Post im Twitter-Entwicklerblog (für den er vermutlich vor allem seinen Namen hergegeben hat, er kann nämlich sonst besser schreiben). Der lautet in der Kurzfassung:
1. Alle API-Endpunkte erfordern künftig Authentifizierung
2. Es wird neue Rate Limits pro Endpunkt geben
3. Third-Party-Clients unterliegen strengeren Auflagen
Sobald die API 1.1 veröffentlicht wird, haben Entwickler sechs Monate Zeit, ihre Applikationen entsprechend anzupassen. Andernfalls droht diesen die Abschaltung.
Sippeys Blogeintrag enthält eine neue grafische Matrix, auf der Twitter die unterschiedlichen auf seine Plattform aufsetzenden Clients in mehr und weniger erwünschte klassifiziert. Auch hier lautet die Kurzfassung: Je mehr Interaktion mit dem Endnutzer, sprich Third-Party-Clients, desto weniger erwünscht; aus Twitter-Sicht in Ordnung sind hingegen Social Analytics, Business-Anwendungen wie Social CRM oder auch Ranking-Dienste wie das häufig aufgrund seiner Intransparenz kritisiert Klout (der namhafte US-Blogger John Gruber nennt Klout aktuell „äußerst aufgeblasenen masturbatorischen Unfug“).
Für Client-Entwickler besonders bedeutsam in dem Sippey-Post ist der Passus unter der Überschrift „Changes to the Developer Rules oft he Road“. Dort kündigt der Twitter-Produktchef unter anderem an, dass die bisherigen Richtlinien zur Darstellung von Tweets künftig verpflichtend sind.
Marco Arment, Entwickler des populären Später-Lesen-Dienstes „Instapaper“, erläutert in seinem Blog verschiedene Detailaspekte dazu genauer. Einige seiner Kernaussagen: Das Einbetten von Tweets auf externen Webseiten anders als über den von Twitter angebotenen dynamischen Code (zum Beispiel einfach via Link und Zitat) ist de facto untersagt, das Teilen von Links auf Tweets in anderen Social Services vermutlich ebenso; außerdem darf man via pic.twitter.com geteilte Fotos nicht allein und losgelöst vom jeweiligen Tweet anzeigen.
Besonders problematisch und weitreichend ist aus Sicht von Arment Absatz 5a der Display Guidelines. Der schreibt nämlich vor, dass zu einer Timeline gruppierte Twitter-Kurznachrichten keinesfalls zusammen mit Nicht-Twitter-Inhalten wie Kommentaren oder Updates aus anderen Netzen dargestellt werden dürfen. Arment vermutet, dass genau diese Auflage zu dem Disput mit LinkedIn (wo Tweets nicht mehr als Updates einlaufen) und dem Rückzug von Flipboard-Chef Mike McCue aus dem Twitter-Verwaltungsrat geführt hat. Er rechnet außerdem damit, dass alle Clients künftig von Twitter eingestreute Werbung anzeigen müssen und keine Filter- und „Stummschalt“-Funktionen mehr haben dürfen.
Twitter wird laut Sippey externe Entwickler künftig häufiger zu einer direkten Zusammenarbeit mit dem Plattformanbieter nötigen. Vereinfacht gesagt: Sobald eine Twitter-Applikationen eine gewisse Größe erreicht, braucht sie den offiziellen Segen von Twitter. Auf diesen angewiesen sind insbesondere Developer, die für ihre Lösung eine große Zahl von individuellen Nutzer-Tokens (konkret: mehr als 100.000) benötigen oder auf die „User Streams“ zugreifen wollen.
Applikationen, die mehr als diese 100 K User Tokens nutzen, will Twitter übrigens nicht gleich abschalten. Sie dürfen immerhin noch doppelt so viele Nutzer sammeln wie sie heute haben (solange sie sich an die „Rules of the Road“ halten, versteht sich); neue dürfen dann allerdings nur noch mit Erlaubnis von Twitter dazukommen. Sippey deutet außerdem vage an, dass möglicherweise noch weitere Änderungen an den „Rules of the Road“ erfolgen könnten, „um die hier dargelegten funktionalen Änderungen in Version 1.1 der Twitter-API zu reflektieren“.
Verständlicher, aber gefährlicher Wunsch nach mehr Kontrolle
Nick Bilton schreibt bei der „New York Times“, aus Business-Sicht sei die angekündigte Limitierung der API durch Twitter ein „Versuch, sein Geschäft zu rationalisieren und zu kontrollieren“. Schon im vergangenen Jahr hatte Twitter mitgeteilt, dass mehr als eine Million Applikationen seine Plattform nutzen – und all diese zu beliefern kostet die Firma fraglos eine Menge Rechenleistung und Manpower.
Diese Kosten im Griff zu haben ist ein ebenso verständlicher Wunsch wie der nach dem Eindämmen von Bots und Spam-Accounts. Viele Entwickler von Third-Party-Clients – und auch deren teils sehr loyale Nutzergemeinden – stößt Twitter allerdings gehörig vor den Kopf, wie man einigen der von „GigaOm“ geposteten ersten Reaktionen eindeutig entnehmen kann. Dabei sollte man nicht vergessen, dass Twitter selbst ohne Third-Party-Apps wie „Tweetie“ (das sogar heute noch immer den Großteil der offiziellen iPad-App von Twitter ausmacht) wohl kaum da stünde, wo es heute steht.
Wie harsch Twitter mit seinem Entwickler-Ökosystem nach Inkrafttreten der neuen API tatsächlich umgeht und wie Developer und Endnutzer darauf reagieren, bleibt vorerst abzuwarten. Mit App.net steht jedenfalls schon ein durch Crowdfunding finanzierter Rivale in den Startlöchern. Und der oder auch irgendein Dienst, den wir heute noch gar nicht kennen, könnte ganz schnell das „next big thing“ im Social Web werden, wenn Twitter es sich mit seinen Developern und Usern verscherzt.
* Thomas Cloer ist Redakteur der deutschen Computerwoche.

Mehr Artikel

News

Große Sprachmodelle und Data Security: Sicherheitsfragen rund um LLMs

Bei der Entwicklung von Strategien zur Verbesserung der Datensicherheit in KI-Workloads ist es entscheidend, die Perspektive zu ändern und KI als eine Person zu betrachten, die anfällig für Social-Engineering-Angriffe ist. Diese Analogie kann Unternehmen helfen, die Schwachstellen und Bedrohungen, denen KI-Systeme ausgesetzt sind, besser zu verstehen und robustere Sicherheitsmaßnahmen zu entwickeln. […]

Be the first to comment

Leave a Reply

Your email address will not be published.


*