Skip to main content

​
Likes-Lookup: Standard v1.1 im Vergleich zur X API v2

Wenn Sie mit dem Standard v1.1 GET favorites/list endpoint gearbeitet haben, soll Ihnen dieser Leitfaden helfen, die Gemeinsamkeiten und Unterschiede zwischen Standard v1.1 und den Likes-Lookup-endpoints der X API v2 zu verstehen. Mit v2 haben wir außerdem einen neuen liked users endpoint eingeführt, mit dem Sie Informationen über die Nutzer abrufen können, die einen Post geliked haben.
  • Gemeinsamkeiten
    • Authentifizierung
    • Rate Limits
  • Unterschiede
    • Endpoint-URLs
    • Anfragerestriktionen
    • Anforderungen für App und Project
    • Anfrageparameter
    • Neues JSON-Format

​
Gemeinsamkeiten

Authentifizierung Sowohl die Standard v1.1- als auch die X API v2 Likes-Lookup-endpoints verwenden OAuth 1.0a User Context oder OAuth 2.0 Bearer Token. Wenn Sie zuvor die Standard v1.1-GET favorites/list endpoints verwendet haben, können Sie beim Wechsel zur X API v2-Version weiterhin dieselbe Authentifizierungsmethode verwenden, wenn Sie möchten.  Je nach verwendeter Authentifizierungsbibliothek bzw. -paket ist die Bearer-Token-Authentifizierung wahrscheinlich der einfachste Einstieg und kann über einen einfachen Request-Header gesetzt werden. Informationen zur Generierung eines Bearer Tokens finden Sie in dieser OAuth 2.0 Bearer Token-Anleitung.    Rate Limits Der Standard v1.1-GET favorites/list-endpoint hat ein Rate Limit von 75 Requests pro 15 Minuten und Nutzer. Der entsprechende liked Posts-endpoint in v2 hat dasselbe Rate Limit. Allerdings hat dieser v2-endpoint zusätzlich ein Rate Limit von 75 Requests pro 15 Minuten und App.

​
Unterschiede

Endpoint-URLs Anfragebeschränkungen Der v2 Endpoint für liked Posts ermöglicht 5 bis 100 Posts pro Anfrage, allerdings können Sie mithilfe von Paginierungs‑Tokens alle likes eines Posts abrufen. Der v1.1 GET Endpoint favorites/list ermöglicht ebenfalls, alle likes von Posts abzurufen, jedoch können Sie pro Anfrage 20 bis 200 Posts abrufen. Für den v2 Endpoint liking users sind Sie auf 100 liking users pro Post beschränkt.    App- und Project-Anforderungen Die X API v2 Endpoints erfordern, dass Sie Anmeldedaten aus einer Developer-App verwenden, die beim Authentifizieren Ihrer Anfragen einem Project zugeordnet ist. Alle X API v1.1 Endpoints können Anmeldedaten von eigenständigen Apps oder Apps verwenden, die einem Project zugeordnet sind. Anfrageparameter Die folgenden Standard-v1.1-Anfrageendpunkte akzeptierten zwei Abfrageparameter (user_id oder screen_name). Die X API v2 akzeptiert nur die numerische Nutzer-ID, und sie muss als Teil des Endpoint-Pfads übergeben werden. Einer der größten Unterschiede zwischen Standard v1.1 und X API v2 Endpoint-Versionen ist, wie Sie auswählen, welche Felder in Ihrer Payload zurückgegeben werden. Für die Standard-Endpunkte gibt es mehrere Parameter, mit denen Sie angeben konnten, welche Felder oder Feldsätze in der Payload zurückgegeben werden, während die X API v2 Version diese verschiedenen Parameter in fields und expansions vereinheitlicht.    Neues JSON-Format X API v2 führt neue JSON-Designs für die von den APIs zurückgegebenen Objekte ein, einschließlich Post- und user-Objekten.
  • Auf JSON-Root-Ebene geben die Standard-Endpunkte User-Objekte in einem statuses-Array zurück, während X API v2 ein data-Array zurückgibt. 
  • Anstatt sich auf Retweeted- und Quoted-„statuses“ zu beziehen, verweist X API v2 JSON auf Retweeted und Quoted Tweets. Viele Legacy- und veraltete Felder, wie contributors und user.translator_type, werden entfernt. 
  • Anstatt sowohl favorites (im Post-Objekt) als auch favourites (im User-Objekt) zu verwenden, nutzt X API v2 den Begriff like. 
  • X übernimmt die Konvention, dass JSON-Werte ohne Wert (zum Beispiel null) nicht in die Payload geschrieben werden. Post- und User-Attribute werden nur aufgenommen, wenn sie nicht null sind.  
Zusätzlich zu den Änderungen am neuen JSON-Format haben wir dem Post-Objekt auch einen neuen Satz von Feldern hinzugefügt, darunter die folgenden:
⌘I