Zum Hauptinhalt springen
Dieses endpoint wurde aktualisiert, um Bearbeitungs-metadata für Posts einzuschließen. Erfahren Sie mehr über diese metadata auf der Seite zu den Grundlagen von “Posts bearbeiten”. 

​
Decahose-Stream

Enterprise Dies ist eine Enterprise-API, die ausschließlich innerhalb unserer verwalteten Zugriffsstufen verfügbar ist. Um diese API zu nutzen, müssen Sie zunächst ein Konto über unser Enterprise-Vertriebsteam einrichten. Weitere Informationen Die Decahose liefert über eine Streaming-Verbindung eine zufällige 10%-Stichprobe des Echtzeit-X-Firehose. Dies erfolgt mittels eines Echtzeit-Sampling-Algorithmus, der die data zufällig auswählt und dabei dennoch eine erwartungsgemäß latenzarme Zustellung der data ermöglicht, während sie von X über den Firehose gesendet wird. Im Folgenden sind einige der mit der Decahose verfügbaren Funktionen aufgeführt:
  • Erweiterte und aufgewertete URLs: - löst verkürzte URLs vollständig auf und stellt zusätzliche metadata bereit (Seitentitel und -beschreibung)
  • Stream-Partitionierung - 2 Partitionen, die jeweils 50% des Volumens des Decahose-Streams enthalten
  • Erhöhte Zuverlässigkeit - geografische Diversifizierung der Backendsysteme
Hinweis: Diese data wird in Bulk geliefert und unterstützt keine zusätzliche Filterung (z. B. nach Schlüsselwörtern). ENTERPRISE

​
Streaming-Likes

Dies ist eine Enterprise-API, die nur innerhalb unserer verwalteten Zugriffsstufen verfügbar ist. Um diese API zu nutzen, müssen Sie zunächst ein Konto über unser Enterprise-Vertriebsteam einrichten. Weitere Informationen Likes ermöglichen Einblicke, wer Posts liked, und liefern genaue Like-Zählungen. Gnips Firehose und Decahose können öffentliche Likes zu den über Gnip gelieferten Posts bereitstellen. Dies liefert Echtzeitkennzahlen zum öffentlichen Engagement und zur Zielgruppe, die einem Post zugeordnet sind.   Erste Schritte mit Likes Wenn Sie sich auf die Nutzung von Likes-Daten vorbereiten, sollten Sie wissen:
  • Likes werden über einen unabhängigen, separaten Stream geliefert
  • Likes wurden früher als „Favorites“ bezeichnet. Die angereicherte native Payload behält diese Nomenklatur bei
  • Streams enthalten nur öffentliche Likes
    • Öffentlich bedeutet, dass der likende Nutzer, der Post-Ersteller und der Post auf der Plattform jeweils öffentlich sind
  • Likes sind Retweets sehr ähnlich und stellen ein öffentliches Signal für Engagement dar
  • Payload-Elemente umfassen:
    • Ursprüngliches Post-Objekt
    • Actor-Objekt, das den ursprünglichen Post erstellt hat
    • Actor-Objekt, das die Like-Aktion ausgeführt hat
  • Nur Originalinhalte können geliked werden
    • Retweets können nicht geliked werden. Ein Like auf einen Retweet wird auf den ursprünglichen Post angewendet
    • Zitierte Tweets können geliked werden
  • Like-Aktivitäten enthalten anwendbare Gnip Enrichments (falls erworben/angewendet)
  • Unterstützte Produkte/Funktionen
    • Likes-Streams unterstützen Backfill (falls erworben/angewendet)
    • Es gibt keinen Replay-Support für Likes-Streams
    • Es gibt keinen Search- oder Historical-Support für Likes
    • Es gibt derzeit keine unmittelbaren Pläne, Likes-Support zu PowerTrack hinzuzufügen
Decahose Native angereicherte Payload 
{
   "id":"43560406e0ad9f68374445f5f30c33fc",
   "created_at":"Thu Dec 01 22:27:39 +0000 2016",
   "timestamp_ms":1480631259353,
   "favorited_status":{
      "created_at":"Thu Dec 01 22:27:16 +0000 2016",
      "id":804451830033948672,
      "id_str":"804451830033948672",
      "text":"@kafammheppduman",
      "source":"\u003ca href=\"http:\/\/x.com\/download\/android\" rel=\"nofollow\"\u003eX für Android\u003c\/a\u003e",
      "truncated":false,
      "in_reply_to_status_id":803694205163814912,
      "in_reply_to_status_id_str":"803694205163814912",
      "in_reply_to_user_id":2855759795,
      "in_reply_to_user_id_str":"2855759795",
      "in_reply_to_screen_name":"kafammheppduman",
      "user":{
         "id":2855759795,
         "id_str":"2855759795",
         "name":"delirdim kanka",
         "screen_name":"kafammheppduman",
         "location":"sanane",
         "url":"http:\/\/instagram.com\/kafammheppduman",
         "description":"Manit @GalatasaraySk \ud83d\udc9e",
         "translator_type":"none",
         "protected":false,
         "verified":false,
         "followers_count":3702,
         "friends_count":607,
         "listed_count":1,
         "favourites_count":113338,
         "statuses_count":389,
         "created_at":"Sat Nov 01 22:38:25 +0000 2014",
         "utc_offset":null,
         "time_zone":null,
         "geo_enabled":true,
         "lang":"tr",
         "contributors_enabled":false,
         "is_translator":false,
         "profile_background_color":"C0DEED",
         "profile_background_image_url":"",
         "profile_background_image_url_https":"",
         "profile_background_tile":false,
         "profile_link_color":"1DA1F2",
         "profile_sidebar_border_color":"C0DEED",
         "profile_sidebar_fill_color":"DDEEF6",
         "profile_text_color":"333333",
         "profile_use_background_image":true,
       "Profile_image_url": "http:\/\/pbs.twimg.com\/profile_images\/804421763945861121\/v3bp9pnq_normal.jpg",
         "Profile_image_url_https": "https:\/\/pbs.twimg.com\/profile_images\/804421763945861121\/v3bp9pnq_normal.jpg",
         "profile_banner_url":"https:\/\/pbs.twimg.com\/profile_banners\/2855759795\/1480630085",
         "default_profile":true,
         "default_profile_image":false,
         "following":null,
         "follow_request_sent":null,
         "notifications":null
      },
      "geo":null,
      "coordinates":null,
      "place":null,
      "contributors":null,
      "is_quote_status":false,
      "retweet_count":0,
      "favorite_count":0,
      "entities":{
         "hashtags":[],
         "urls":[],
         "user_mentions":[
            {
               "screen_name":"kafammheppduman",
               "name":"delirdim kanka",
               "id":2855759795,
               "id_str":"2855759795",
               "indices":[
                  0,
                  16
               ]
            }
         ],
         "symbols":[]
      },
      "favorited":false,
      "retweeted":false,
      "filter_level":"low",
      "lang":"und"
   },
   "user":{
      "id":774146932365070336,
      "id_str":"774146932365070336",
      "name":"Uyuyan Adam",
      "screen_name":"saykoMenn",
      "location":"Tarsus, T\u00fcrkiye",
      "url":"http:\/\/connected2.me\/pmc1i",
      "description":null,
      "translator_type":"none",
      "protected":false,
      "verified":false,
      "followers_count":414,
      "friends_count":393,
      "listed_count":0,
      "favourites_count":9868,
      "statuses_count":370,
      "created_at":"Fri Sep 09 07:26:26 +0000 2016",
      "utc_offset":null,
      "time_zone":null,
      "geo_enabled":false,
      "lang":"tr",
      "contributors_enabled":false,
      "is_translator":false,
      "profile_background_color":"F5F8FA",
      "profile_background_image_url":"",
      "profile_background_image_url_https":"",
      "profile_background_tile":false,
      "profile_link_color":"1DA1F2",
      "profile_sidebar_border_color":"C0DEED",
      "profile_sidebar_fill_color":"DDEEF6",
      "profile_text_color":"333333",
      "profile_use_background_image":true,
      "Profile_image_url": "http:\/\/pbs.twimg.com\/profile_images\/802992813424201728\/VMzcTL3x_normal.jpg",
      "Profile_image_url_https": "https:\/\/pbs.twimg.com\/profile_images\/802992813424201728\/VMzcTL3x_normal.jpg",
      "profile_banner_url":"https:\/\/pbs.twimg.com\/profile_banners\/774146932365070336\/1480283382",
      "default_profile":true,
      "default_profile_image":false,
      "following":null,
      "follow_request_sent":null,
      "notifications":null
   }
}
Like-DELETE-/„Unlike“-Payload 
{
   "delete":{
      "favorite":{
         "tweet_id":696615514970279937,
         "tweet_id_str":"696615514970279937",
         "user_id":2510287578,
         "user_id_str":"2510287578"
      },
      "timestamp_ms":"1480437031205"
   }
}

​
Anleitungen

​
Wiederherstellung und Redundanz

Einführung  Beim Streamen großer Mengen an Echtzeit-Posts gelten Best Practices, die sowohl die Datenzuverlässigkeit als auch die vollständige Datentreue sicherstellen. Beim Konsumieren von Echtzeitdaten ist die Maximierung der Verbindungszeit ein grundlegendes Ziel. Treten Verbindungsabbrüche auf, müssen diese automatisch erkannt und die Verbindung wiederhergestellt werden. Nach dem erneuten Verbinden ist zu prüfen, ob Zeiträume bestehen, für die Daten nachgeholt werden müssen. Die Komponente, die diese Details verwaltet und Echtzeit-Posts konsumiert, ist nur ein Teil eines Systems mit Anforderungen an Netzwerk, Datenspeicher, Server und Storage. Angesichts der Komplexität dieser Systeme empfiehlt es sich außerdem, unterschiedliche Streaming-Umgebungen zu betreiben – mindestens getrennte Streams für Entwicklung/Tests und Produktion. Decahose bietet eine Reihe von Funktionen, die diese Maßnahmen unterstützen.
  1. Zur Unterstützung mehrerer Umgebungen können wir zusätzliche Streams für Ihr Konto bereitstellen. Diese Streams sind voneinander unabhängig und haben ein eigenes stream_label, um sie zu unterscheiden.
  2. Zur Stabilisierung der Verbindung unterstützt jeder Decahose-Stream redundante Verbindungen. Die gängigste Architektur ist, dass ein Stream zwei Verbindungen hat, und auf der Client-Seite zwei unabhängige Consumer laufen – idealerweise in unterschiedlichen Netzwerken. Mit diesem Design entsteht Redundanz über die clientseitigen Netzwerke, Server und Datenspeicherpfade hinweg. Beachten Sie, dass auf jeder Verbindung eine vollständige Kopie der Daten geliefert wird und die Client-Seite Duplikate tolerieren und handhaben muss.
  3. Alle 10 Sekunden wird ein „Heartbeat“ gesendet; beim Decahose-Stream ist das Datenvolumen jedoch so hoch, dass bereits eine kurze Phase (z. B. einige Sekunden) ohne Posts auf ein Verbindungsproblem hinweisen kann. Daher können sowohl eine „Datensilence“ als auch das Ausbleiben eines Heartbeats zur Erkennung eines Verbindungsabbruchs verwendet werden.
Da Verbindungsabbrüche auftreten werden, verfügt der Decahose-Stream über dedizierte Funktionen für Wiederherstellung und Backfill, um Daten nachzuholen, die aufgrund von Verbindungsunterbrechungen und anderen Betriebsproblemen verpasst wurden.

​
Zusätzliche Streams

Zusätzliche Decahose-Streams sind eine weitere Möglichkeit, die Zuverlässigkeit Ihrer Lösung zu erhöhen. Alle zusätzlichen Streams sind vollständig unabhängig und verfügen über ihr eigenes endpoint. Jedem Stream wird ein eigenes stream_label zugewiesen, und dieses Label ist zusammen mit Ihrem Kontonamen Teil der URL dieses Streams. Siehe das folgende Beispiel: https://gnip-stream.x.com/stream/sample10/accounts/:account_name/publishers/twitter/:stream_label.json Die gängigste Praxis ist, einen Echtzeit-Stream für Ihr Produktionssystem zu reservieren und einen zusätzlichen Stream für Entwicklung und Test bereitzustellen. Ein Test-/Entwicklungs-Stream ermöglicht Decahose-Kunden, Client-Consumer-Updates zu erproben. Obwohl jedem Stream ein (eindeutiges) Label zugewiesen werden kann, ist es üblich, „prod“ für den Produktions-Stream und „dev“ oder „sandbox“ für einen zusätzlichen Entwicklungs-Stream zu verwenden. Die Anzahl der Streams und ihre eindeutigen Labels werden von Ihrem Account-Ansprechpartner konfiguriert. Redundante Verbindungen Eine redundante Verbindung ermöglicht es Ihnen, mehr als eine gleichzeitige Verbindung zum Daten-Stream herzustellen. Dadurch entsteht Redundanz, indem Sie zwei separate Consumer mit demselben Stream verbinden und über beide Verbindungen dieselben Daten empfangen. So verfügt Ihre App über ein Hot-Failover für verschiedene Situationen, z. B. wenn ein Stream getrennt wird oder der primäre Server Ihrer App ausfällt. Die Anzahl der für einen bestimmten Stream zulässigen Verbindungen wird von Ihrem Account-Ansprechpartner konfiguriert. Um einen redundanten Stream zu verwenden, verbinden Sie sich einfach mit derselben URL wie bei Ihrer primären Verbindung. Die Daten für Ihren Stream werden über beide Verbindungen gesendet; beide Stream-Verbindungen werden auf dem Stream-Dashboard angezeigt. Beachten Sie, dass wir für Abrechnungszwecke die Aktivitätszählungen, die Sie über mehrere Verbindungen erhalten, deduplizieren, sodass Ihnen jede eindeutige Aktivität nur einmal in Rechnung gestellt wird. Da der Decahose zwei Partitionen hat, finden Sie nachfolgend ein Beispiel dafür, wie die Verbindungsanzahl funktioniert: Connect to decahose partition=1 Connect to decahose partition=1 Connect to decahose partition=2 Die oben beschriebene Situation ergibt insgesamt drei Verbindungen – zwei Verbindungen zu partition=1 und eine Verbindung zu partition=2. Normalerweise möchten Sie die gleiche Anzahl von Verbindungen zu jeder Partition; dieses Beispiel zeigt daher eine Situation, in der die redundante Verbindung zu partition=2 abgebrochen ist und weiter untersucht werden sollte. Wiederherstellung

​
Übersicht 

Recovery ist ein Tool zur Datenwiederherstellung (nicht für die primäre Datenerfassung zu verwenden), das Streaming-Zugriff auf ein rollierendes 5‑Tage‑Fenster aktueller historischer X‑Daten bietet. Es sollte genutzt werden, um Daten in Situationen wiederherzustellen, in denen Ihre konsumierende Anwendung Daten im Echtzeit‑Stream verpasst — sei es aufgrund einer kurzfristigen Trennung oder in anderen Fällen, in denen es Ihnen für einen Zeitraum nicht gelingt, Echtzeitdaten zu erfassen.

​
Verwendung von Recovery 

Mit dem Recovery-Stream kann Ihre App Anfragen stellen, die auf die gleiche Weise funktionieren wie Anfragen an die Echtzeit-Streams. Ihre App muss jedoch Parameter in der URL angeben, die das von Ihnen angeforderte Zeitfenster kennzeichnen. Anders ausgedrückt: Eine Recovery-Anfrage fordert die API auf: „Posts von Zeitpunkt A bis Zeitpunkt B.“ Diese Posts werden dann über Ihre Streaming-Verbindung in einer Weise zugestellt, die den Echtzeit-Stream nachahmt, jedoch mit leicht verzögerter Geschwindigkeit gegenüber Echtzeit. Siehe folgendes Beispiel: “https://stream-data-api.x.com/stream/powertrack/accounts/someAccountName/publishers/twitter/powertrack.json?startTime=2023-07-05T17:09:12.070Z” Posts werden beginnend mit der ersten (ältesten) Minute des angegebenen Zeitraums zugestellt und chronologisch fortgesetzt, bis die letzte Minute geliefert wurde. Zu diesem Zeitpunkt wird eine Nachricht „Recovery Request Completed“ über die Verbindung gesendet und die Verbindung anschließend vom Server geschlossen. Wenn Ihre Anfrage zu einem Zeitpunkt beginnt, an dem wenige oder keine passenden Ergebnisse auftraten, kann es etwas dauern, bis die ersten Ergebnisse geliefert werden – data wird geliefert, sobald Recovery in dem zu diesem Zeitpunkt verarbeiteten Teil des Archivs Übereinstimmungen findet. Wenn keine Ergebnisse zur Lieferung verfügbar sind, sendet der Stream weiterhin Wagenrückläufe bzw. „Heartbeats“ über die Verbindung, um zu verhindern, dass ein Timeout auftritt. Recovery ist als Tool gedacht, um Daten, die durch kurze Verbindungsabbrüche verpasst wurden, einfach wiederherzustellen – nicht für sehr lange Zeiträume wie einen ganzen Tag. Falls eine Wiederherstellung von Daten über längere Zeiträume erforderlich ist, empfehlen wir, längere Anfragen in kürzere Zeitfenster (z. B. zwei Stunden) aufzuteilen, um die Wahrscheinlichkeit einer Unterbrechung während der Anfrage aufgrund von Instabilitäten im Internet oder aus anderen Gründen zu verringern und um mehr Transparenz über den Fortschritt langer Anfragen zu bieten.

​
Datenverfügbarkeit

Sie können die Recovery-Funktion verwenden, um verpasste Daten der letzten 24 Stunden wiederherzustellen, wenn Sie sich nicht innerhalb des 5‑Minuten‑Backfill‑Fensters erneut verbinden können. Die Streaming‑Recovery‑Funktion ermöglicht ein erweitertes Backfill‑Fenster von 24 Stunden. Recovery erlaubt es, den Zeitraum mit verpassten Daten „wiederherzustellen“. Ein Recovery‑Stream wird gestartet, wenn Sie eine Verbindungsanfrage mit den Anfrageparametern ‘start_time’ und ‘end_time’ stellen. Sobald die Verbindung hergestellt ist, streamt Recovery den angegebenen Zeitraum erneut und trennt anschließend die Verbindung. Sie können zwei gleichzeitige Anfragen an Recovery stellen, d. h. „zwei Recovery‑Jobs“. Recovery funktioniert technisch auf die gleiche Weise wie Backfill, außer dass eine Start- und Endzeit definiert ist. Ein Recovery‑Zeitraum gilt für einen einzelnen Zeitbereich.

​
Backfill

Um Backfill anzufordern, müssen Sie Ihrer Verbindungsanfrage den Parameter backfillMinutes=N hinzufügen, wobei N die Anzahl der Minuten (1–5, nur ganze Zahlen) ist, die beim Herstellen der Verbindung aufgefüllt werden sollen. Wenn Sie beispielsweise für 90 Sekunden getrennt sind, sollten Sie backfillMinutes=2 zu Ihrer Verbindungsanfrage hinzufügen. Da diese Anfrage Backfill für 2 Minuten bereitstellt, einschließlich des 30‑Sekunden‑Zeitraums vor Ihrer Trennung, muss Ihre Consumer-App gegenüber doppelten Daten tolerant sein. Eine beispielhafte Decahose-Verbindungsanforderungs-URL, die ein 5‑minütiges Backfill für Partition 1 anfordert, sieht wie folgt aus: https://gnip-stream.x.com/stream/sample10/accounts/:account_name/publishers/twitter/:stream_label.json?partition=1&backfillMinutes=5 HINWEISE:
  • Sie haben die Möglichkeit, bei der Verbindung stets „backfillMinutes=5“ zu verwenden und anschließend alle bereitgestellten doppelten Daten zu behandeln.
  • Wenn Sie länger als fünf Minuten getrennt sind, können Sie Daten mithilfe von Recovery wiederherstellen.
Wiederherstellung nach Trennung Das Neustarten und die Wiederherstellung nach einer Trennung umfasst mehrere Schritte:
  • Bestimmung der Dauer des Trennungszeitraums.
    • 5 Minuten oder weniger?
      • Wenn Sie Backfill für den Stream aktiviert haben, bereiten Sie die Verbindungsanfrage mit dem entsprechenden Parameter „backfillMinutes“ vor.
    • Mehr als 5 Minuten?
      • Wenn Sie einen Recovery-Stream haben, stellen Sie eine Recovery-Anfrage für den getrennten Zeitraum (idealerweise mit Ihrem aktuellen Realtime-Regelsatz, bei Bedarf mit der Rules API).
  • Fordern Sie eine neue Verbindung an.
Wenn Sie Trennungen oder Ausfallzeiten erleben, finden Sie hier Strategien zur Minderung und Wiederherstellung in diesem Szenario:
  1. Backfill implementieren Backfill ermöglicht es Ihnen, ab einem Zeitpunkt vor der Trennung von einer Stream-Verbindung erneut zu verbinden, und deckt Trennungen von bis zu 5 Minuten ab. Dies wird umgesetzt, indem ein Parameter in die Verbindungsanfrage aufgenommen wird.
  2. Einen redundanten Stream von einem anderen Standort konsumieren Wenn der redundante Stream in dieselbe Live-Umgebung eingespeist werden kann und dabei Daten dedupliziert werden, entfällt die Notwendigkeit einer Wiederherstellung, es sei denn, SOWOHL der normale Stream als auch der redundante Stream haben gleichzeitig Ausfallzeiten oder Trennungen. Wenn der redundante Stream nicht live in die Produktionsumgebung eingespeist werden kann, kann er in einen separaten „Notfall“-Datenspeicher geschrieben werden. Dann hat Ihr System im Falle von Trennungen oder Ausfallzeiten bei der primären Stream-Verbindung Daten zur Hand, um Ihre primäre Datenbank für den Zeitraum zu ergänzen, in dem Daten fehlen.
  3. Recovery implementieren Wenn Trennungen oder Ausfallzeiten sowohl den primären Stream als auch den redundanten Stream betreffen, verwenden Sie Decahose Recovery, um verpasste Daten wiederherzustellen. Die API bietet ein rollierendes Fenster, das 5 Tage des Archivs abdeckt, und wird am besten genutzt, indem Sie jeweils nicht mehr als eine Stunde dieses Fensters anfordern und einspielen. Dies geschieht parallel zum Realtime-Stream. Beachten Sie, dass wir keine Lösungen zur Wiederherstellung von Decahose-Daten über das durch Recovery bereitgestellte 5‑Tage‑Fenster hinaus anbieten. Es ist daher wichtig, einen redundanten Stream zu nutzen, um sicherzustellen, dass Sie bei erheblichen Ausfallzeiten auf Ihrer Seite eine vollständige Kopie der Daten auf Ihrer Seite haben.
Wenn Sie anormale gespeicherte Datenmengen feststellen – Mögliche Wege, wie Sie fehlende Daten erkennen können, obwohl keine Trennungen oder Ausfallzeiten aufgetreten sind …
  1. Eingehende Posts zählen Ihr System sollte die Rohanzahl der Posts zählen, die Sie ganz am Anfang Ihrer Ingestion-App erhalten, und dann eine Möglichkeit bieten, diese Zahlen mit der Anzahl der Posts zu vergleichen, die Ihren endgültigen Datenspeicher erreichen. Alle Abweichungen können überwacht werden und Ihr Team auf Probleme aufmerksam machen, die dazu führen, dass Daten nach dem Empfang verworfen werden.
  2. Analyse auf anormale gespeicherte Volumina Sie sollten auch die Volumina der gespeicherten Daten in Ihrer endgültigen Datenbank analysieren, um nach ungewöhnlichen Rückgängen zu suchen. Dies kann ebenfalls auf Probleme hinweisen, wobei es wahrscheinlich Situationen gibt, in denen Rückgänge im Volumen normal sind (z. B. wenn die X Plattform nicht verfügbar ist und Personen für einen bestimmten Zeitraum keine Posts erstellen können).

​
API-Referenz

​
Decahose-Stream

Zu diesem Abschnitt springen Methoden Authentifizierung GET /{stream-type}/:stream Replay-API

​
Methoden

MethodeBeschreibung
GET /{stream-type}/:streamMit dem Datenstream verbinden

​
Authentifizierung

Alle Anfragen an die Volume Stream APIs müssen HTTP Basic Authentication verwenden, aufgebaut aus einer gültigen Kombination aus E‑Mail‑Adresse und Passwort, mit der Sie sich bei Ihrem Konto unter console.gnip.com anmelden. Die Anmeldeinformationen müssen bei jeder Anfrage im Authorization‑Header übermittelt werden. Vergewissern Sie sich daher, dass Ihr Client den HTTP‑Header „Authorization: Basic“ (mit über HTTPS übermittelten, codierten Anmeldeinformationen) zu allen API‑Anfragen hinzufügt.

​
GET :stream

Stellt eine dauerhafte Verbindung zum Firehose-Stream her, über die die Echtzeitdaten ausgeliefert werden.

​
Anforderungsspezifikationen

AnforderungsmethodeHTTP GET
VerbindungstypKeep-Alive

Dies sollte im Header der Anfrage angegeben werden.
URLAuf der API-Hilfeseite des Streams in Ihrem Dashboard zu finden, mit folgender Struktur:

Decahose:

https://gnip-stream.x.com/stream/sample10/accounts/:account_name/publishers/twitter/:stream_label.json?partition=1
Partition (erforderlich)partition=\{#} - Partitionierung ist jetzt erforderlich, um den vollständigen Stream zu beziehen. Sie müssen mit dem angegebenen Parameter „partition“ eine Verbindung zum Stream herstellen. Unten finden Sie die Anzahl der Partitionen pro Stream:

* Decahose: 2 Partitionen
KompressionGzip. Um den Stream mit Gzip-Komprimierung zu nutzen, senden Sie in der Verbindungsanfrage einen Accept-Encoding-Header. Der Header sollte wie folgt aussehen:

Accept-Encoding: gzip
ZeichenkodierungUTF-8
AntwortformatJSON. Der Header Ihrer Anfrage sollte JSON als Antwortformat angeben.
Rate Limit10 Anfragen pro 60 Sekunden.
Backfill-ParameterWenn Sie einen Stream mit aktiviertem Backfill erworben haben, müssen Sie den Parameter „backfillMinutes“ in die GET-Anfrage aufnehmen, um ihn zu aktivieren.
Read TimeoutSetzen Sie auf Ihrem Client ein Read-Timeout und stellen Sie sicher, dass es auf einen Wert von mehr als 30 Sekunden konfiguriert ist.
Unterstützung für Tweet-BearbeitungenAlle Tweet-Objekte enthalten Tweet-Edit-Metadata, die die Bearbeitungshistorie des Tweets beschreiben. Weitere Details finden Sie auf der Grundlagen-Seite „Edit Tweets“ (/x-api/enterprise-gnip-2.0/fundamentals/edit-tweets) und in der englischen Version der Seite: Edit Tweets.

​
Antworten

Die folgenden Antworten kann die API auf diese Anfragen zurückgeben. Die meisten Fehlercodes werden mit einer Zeichenfolge mit zusätzlichen Details im Body zurückgegeben. Bei Antworten ungleich 200 sollten Clients versuchen, die Verbindung erneut herzustellen.
StatusTextBeschreibung
200ErfolgDie Verbindung wurde erfolgreich geöffnet und neue Aktivitäten werden gesendet, sobald sie eintreffen.
401Nicht autorisiertHTTP-Authentifizierung aufgrund ungültiger Anmeldedaten fehlgeschlagen. Melden Sie sich mit Ihren Anmeldedaten bei console.gnip.com an, um sicherzustellen, dass Sie sie in Ihrer Anfrage korrekt verwenden.
406Nicht akzeptabelDies tritt in der Regel auf, wenn Ihr Client die Header zum Akzeptieren der gzip-Codierung aus dem Stream nicht korrekt angibt, kann jedoch auch unter anderen Umständen auftreten.

Enthält eine JSON-Nachricht ähnlich wie „Diese Verbindung erfordert Komprimierung. Um die Komprimierung zu aktivieren, senden Sie einen ‚Accept-Encoding: gzip‘-Header in Ihrer Anfrage und seien Sie bereit, den Stream auf der Client-Seite beim Lesen zu dekomprimieren.“
429Rate Limit überschrittenIhre App hat das Limit für Verbindungsanfragen überschritten.
503Dienst nicht verfügbarServerproblem bei Twitter. Stellen Sie die Verbindung mithilfe eines exponentiellen Backoff-Musters wieder her. Wenn auf der X API Status Page keine Mitteilung zu diesem Problem veröffentlicht wurde, wenden Sie sich an den Support oder an den Notdienst, wenn nach 10 Minuten keine Verbindung möglich ist.

​
Beispiel-cURL-Anfrage

Die folgende Beispielanfrage wird mit cURL in der Befehlszeile ausgeführt. Beachten Sie jedoch, dass diese Anfragen auch mit der Programmiersprache Ihrer Wahl gesendet werden können: 
curl --compressed -v -uexample@customer.com "https://gnip-stream.x.com/stream/firehose/accounts/:account\_name/publishers/twitter/:stream\_label.json?partition={#}"

​
Replay-API

Die Replay-API ist eine wichtige Ergänzung zu Echtzeit-Volumenstreams. Replay ist ein Tool zur Datenwiederherstellung, das Streaming-Zugriff auf ein gleitendes Zeitfenster jüngster historischer X-Daten bietet.
⌘I