Decahose API

이 엔드포인트에는 게시물 편집 메타데이터가 포함되도록 업데이트되었습니다. 이러한 메타데이터에 대해 더 알아보려면 “게시물 편집” 기초 페이지를 참조하세요.

​

Decahose 스트림

Enterprise

이는 당사의 관리형 액세스 레벨에서만 제공되는 엔터프라이즈 API입니다. 이 API를 사용하려면 먼저 엔터프라이즈 영업팀과 계정을 개설해야 합니다. 자세히 알아보기

Decahose는 스트리밍 연결을 통해 실시간 X Firehose의 10% 무작위 샘플을 제공합니다. 이는 실시간 샘플링 알고리즘을 통해 이루어지며, 이 알고리즘은 데이터를 무작위로 선택하면서도 X가 firehose를 통해 데이터를 전송할 때 기대되는 저지연 전달을 보장합니다.

아래는 Decahose에서 제공되는 주요 기능입니다:

• 확장 및 고도화된 URL: - 단축 URL을 완전히 해제하고 추가 메타데이터(페이지 제목 및 설명)를 제공합니다
• 스트림 파티셔닝 - 2개의 파티션으로 구성되며, 각 파티션은 Decahose 스트림 볼륨의 50%를 포함
• 향상된 안정성 - 백엔드 시스템의 지리적 분산

참고: 이 데이터는 대량으로 제공되며, 추가 필터링(예: 키워드)은 지원하지 않습니다.

ENTERPRISE

​

좋아요 스트리밍

이는 관리형 액세스 레벨에서만 제공되는 엔터프라이즈 API입니다. 이 API를 사용하려면 먼저 엔터프라이즈 영업팀과 계정을 설정해야 합니다. 자세히 알아보기

좋아요는 누가 게시물을 좋아하는지에 대한 인사이트를 제공하고, 정확한 좋아요 수를 제공합니다. Gnip의 Firehose 및 Decahose는 Gnip을 통해 전달된 게시물과 관련된 공개 좋아요를 제공할 수 있습니다. 이는 특정 게시물과 연관된 실시간 공개 참여 및 오디언스 지표를 제공합니다.  

좋아요 시작하기

좋아요 데이터를 수집하기 전에 다음을 알아두세요:

• 좋아요는 독립적인 별도 스트림으로 전달됩니다
• 좋아요는 과거에 “Favorites”로 불렸습니다. 확장된 네이티브 형식의 페이로드는 이 명칭을 유지합니다
• 스트림에는 공개 좋아요만 포함됩니다
  • 공개란, 좋아요한 사용자, 게시물 작성자, 게시물이 모두 플랫폼에서 공개 상태임을 의미합니다
• 좋아요는 리트윗과 매우 유사하며 공개적인 참여 신호를 나타냅니다
• 페이로드 요소에는 다음이 포함됩니다:
  • 원본 게시물 객체
  • 원본 게시물을 생성한 액터 객체
  • 좋아요 작업을 수행한 액터 객체
• 원본 콘텐츠에만 좋아요를 할 수 있습니다
  • 리트윗에는 좋아요를 할 수 없습니다. 리트윗에 대한 좋아요는 원본 게시물에 적용됩니다
  • 인용 트윗은 좋아요할 수 있습니다
• 좋아요 활동에는 해당되는 경우 Gnip Enrichments가 포함됩니다(구매/적용된 경우)
• 지원 제품/기능
  • 좋아요 스트림은 백필(Backfill)을 지원합니다(구매/적용된 경우)
  • 좋아요 스트림은 리플레이를 지원하지 않습니다
  • 좋아요에는 검색 또는 히스토리컬 지원이 없습니다
  • PowerTrack에 좋아요 지원을 추가할 즉각적인 계획은 없습니다

Decahose

• Decahose에서 제공되는 10% 샘플 게시물의 경우 스트림에는 해당되는 공개 좋아요가 100% 포함됩니다
• 파티션: 2
• URL 구조
  • https://gnip-stream.x.com/stream/sample10-likes/accounts/<accountName>/publishers/twitter/<streamLabel>.json?partition=1

네이티브 확장 형식 페이로드

{
   "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 for 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
   }
}

좋아요 삭제 / “좋아요 취소” 페이로드

{
   "delete":{
      "favorite":{
         "tweet_id":696615514970279937,
         "tweet_id_str":"696615514970279937",
         "user_id":2510287578,
         "user_id_str":"2510287578"
      },
      "timestamp_ms":"1480437031205"
   }
}

​

가이드

​

복구 및 이중화

소개 

대량의 실시간 게시물을 스트리밍할 때에는 데이터 신뢰성과 데이터의 완전성을 모두 보장하기 위한 모범 사례를 따라야 합니다. 실시간 데이터를 수집할 때 연결 시간을 극대화하는 것이 핵심 목표입니다. 연결이 끊기면 이를 자동으로 감지해 재연결하는 것이 중요합니다. 재연결 후에는 보충 수집(backfill)이 필요한 구간이 있는지 평가해야 합니다. 이러한 세부 사항을 관리하고 실시간 게시물을 수집하는 구성 요소는 네트워크, 데이터 저장소, 서버, 스토리지 등 다양한 고려사항을 가진 시스템의 일부에 불과합니다. 이러한 시스템의 복잡성을 고려할 때, 또 다른 모범 사례는 서로 다른 스트리밍 환경을 갖추는 것으로, 최소한 개발/테스트용과 프로덕션용 스트림을 분리하는 것입니다.

Decahose는 이러한 작업을 돕는 기능들을 제공합니다.

1. 여러 환경을 지원하기 위해 계정에 추가 스트림 을(를) 배포할 수 있습니다. 이 스트림들은 서로 독립적이며 구분을 위해 서로 다른 stream_label을 가집니다.
2. 안정적인 연결 유지를 돕기 위해 각 Decahose 스트림은 이중 연결을 지원합니다. 가장 일반적인 아키텍처는 하나의 스트림에 두 개의 연결을 두고, 클라이언트 측에는 이상적으로 서로 다른 네트워크에 위치한 두 개의 독립 소비자(consumer)를 두는 것입니다. 이 설계를 통해 클라이언트 측 네트워크, 서버, 데이터 저장 경로 전반에서 이중화를 확보할 수 있습니다. 각 연결에서는 데이터의 전체 복제본이 제공되므로, 클라이언트 측은 중복 데이터에 내성을 갖고 이를 처리해야 합니다.
3. ‘하트비트’가 10초마다 제공됩니다. 다만 Decahose 스트림의 경우 데이터 양이 충분히 많아 짧은 시간(예: 수 초) 동안 게시물이 없으면 연결 문제를 의미할 수 있습니다. 따라서 ‘데이터 무음’과 하트비트 부재 모두를 이용해 연결 끊김을 감지할 수 있습니다.

연결 끊김은 발생할 수 있으므로, Decahose 스트림에는 중단 및 기타 운영상의 문제로 인해 누락된 데이터를 복구하는 데 도움이 되는 전용 복구 및 백필 기능이 제공됩니다.

​

추가 스트림

추가 Decahose 스트림을 운영하는 것은 솔루션의 안정성과 신뢰성을 높이는 또 다른 방법입니다. 추가 스트림은 서로 완전히 독립적이며 각자 고유한 엔드포인트를 가집니다. 각 스트림에는 고유한 stream_label이 할당되며, 이 레이블은 계정 이름과 함께 해당 스트림 URL의 일부가 됩니다. 아래 예시를 참고하세요:

https://gnip-stream.x.com/stream/sample10/accounts/:account_name/publishers/twitter/:stream_label.json

가장 일반적인 방식은 프로덕션 시스템 전용 실시간 스트림 하나와, 개발 및 테스트용 보조 스트림 하나를 운용하는 것입니다. 테스트/개발 스트림이 있으면 Decahose 고객은 클라이언트 컨슈머 업데이트를 검증할 전용 스트림을 확보할 수 있습니다. 스트림에는 임의의(고유한) 레이블을 지정할 수 있지만, 관례적으로 프로덕션 스트림에는 ‘prod’를, 개발용 추가 스트림에는 ‘dev’ 또는 ‘sandbox’를 사용합니다.

스트림 수와 각 스트림의 고유 레이블은 담당 어카운트 매니저를 통해 구성할 수 있습니다.

중복 연결

중복 연결은 데이터 스트림에 동시에 둘 이상의 연결을 설정할 수 있게 해줍니다. 이는 동일한 스트림에 두 개의 별도 컨슈머로 연결하여 두 연결 모두를 통해 동일한 데이터를 수신함으로써 중복성을 제공합니다. 따라서 한 스트림이 끊기거나 앱의 기본 서버에 장애가 발생하는 등 다양한 상황에서 앱에 즉시 전환 가능한 핫 페일오버를 확보할 수 있습니다.

특정 스트림에 허용되는 연결 수는 담당 어카운트 매니저를 통해 구성할 수 있습니다. 중복 스트림을 사용하려면 기본 연결에 사용한 것과 동일한 URL에 연결하면 됩니다. 스트림 데이터는 두 연결 모두를 통해 전송되며, 두 스트림 연결은 스트림 대시보드에 표시됩니다.

청구를 위해 여러 연결을 통해 수신한 활동 수는 중복 제거하여, 각 고유 활동에 대해서만 한 번 청구됩니다. Decahose에는 두 개의 파티션이 있으므로, 연결 수 계산 예시는 다음과 같습니다:

Connect to decahose partition=1 Connect to decahose partition=1 Connect to decahose partition=2

위 상황에서는 총 세 개의 연결이 됩니다. 즉, partition=1에 두 개, partition=2에 한 개의 연결입니다. 일반적으로는 각 파티션에 동일한 수의 연결을 두는 것이 바람직하므로, 이 예시는 partition=2에 대한 중복 연결이 끊어져 추가 조사가 필요한 상황을 보여줍니다.

복구

​

개요 

Recovery는 최근 X 히스토리 데이터의 롤링 5일치 구간에 스트리밍 방식으로 접근할 수 있는 데이터 복구 도구입니다(기본 데이터 수집 용도로 사용하면 안 됨). 이 도구는 소비 애플리케이션이 실시간 스트림에서 데이터를 놓친 경우(짧은 시간 동안의 연결 해제 등으로 인한 경우 또는 일정 기간 동안 실시간 데이터를 수집하지 못한 기타 모든 상황) 해당 데이터를 복구하는 데 사용해야 합니다.

​

Recovery 사용하기 

Recovery 스트림을 사용하면 앱이 실시간 스트림과 동일한 방식으로 해당 스트림에 요청을 보낼 수 있습니다. 단, 요청하려는 시간 범위를 나타내는 매개변수를 URL에 지정해야 합니다. 즉, Recovery 요청은 API에 “시간 A부터 시간 B까지의 게시물”을 요청하는 것입니다. 이후 이러한 게시물은 실시간 스트림을 모방한 방식으로 스트리밍 연결을 통해 전달되지만, 실시간보다 약간 느린 속도로 전송됩니다. 아래 예시를 참고하세요:

“https://stream-data-api.x.com/stream/powertrack/accounts/someAccountName/publishers/twitter/powertrack.json?startTime=2023-07-05T17:09:12.070Z”

게시물은 지정된 기간의 첫 번째(가장 오래된) 분부터 전달되기 시작해 마지막 분이 전달될 때까지 시간순으로 계속 진행됩니다. 그 시점에 Recovery Request Completed 메시지가 연결을 통해 전송되고, 이후 서버가 연결을 종료합니다. 요청이 매칭되는 결과가 거의 없거나 전혀 없는 시간대에서 시작되면 첫 결과가 전달되기까지 시간이 걸릴 수 있습니다. 데이터는 해당 시점에 처리 중인 아카이브 구간에서 Recovery가 매칭을 발견하는 즉시 전달됩니다. 전달할 결과가 없을 때에는 스트림이 연결을 통해 캐리지 리턴, 즉 “하트비트”를 계속 보내 타임아웃을 방지합니다.

Recovery는 짧은 연결 끊김으로 인해 누락된 데이터를 쉽게 복구하기 위한 도구이며, 하루 전체와 같은 매우 긴 기간에는 적합하지 않습니다. 장기간의 데이터를 복구해야 하는 경우, 더 긴 요청을 더 짧은 시간 창(예: 2시간)으로 분할해 인터넷 불안정 등으로 요청 도중 연결이 끊길 가능성을 줄이고, 장시간 요청의 진행 상황을 더 명확히 파악할 수 있도록 할 것을 권장합니다.

​

데이터 가용성

5분 백필 윈도우 내에 재연결하지 못한 경우, 복구 기능을 사용해 지난 24시간 동안 누락된 데이터를 복원할 수 있습니다.

스트리밍 복구 기능은 백필 윈도우를 최대 24시간으로 확장해 제공합니다. 복구를 통해 누락된 데이터의 시간 구간을 ‘복구’할 수 있습니다. ‘start_time’ 및 ‘end_time’ 요청 매개변수를 사용해 연결 요청을 보내면 복구 스트림이 시작됩니다. 연결되면 복구는 지정된 시간 구간을 다시 스트리밍한 뒤 연결을 종료합니다.  

동시에 최대 2개의 복구 요청, 즉 “두 개의 복구 작업”을 수행할 수 있습니다. 복구는 시작 및 종료 시간을 지정한다는 점을 제외하면 기술적으로 백필과 동일한 방식으로 동작합니다. 복구 기간은 단일 시간 범위에 해당합니다.

​

백필

백필을 요청하려면 연결 요청에 backfillMinutes=N 매개변수를 추가해야 합니다. 여기서 N은 연결 시 백필할 분(1~5, 정수만)입니다. 예를 들어 90초 동안 연결이 끊겼다면 연결 요청에 backfillMinutes=2를 추가해야 합니다. 이 요청은 연결이 끊기기 전 30초를 포함해 2분 동안의 백필을 제공하므로, 사용 중인 소비자 앱에서 중복 데이터에 내성이 있어야 합니다.

다음은 파티션 1에 5분 백필을 요청하는 Decahose 연결 요청 URL의 예시입니다:

https://gnip-stream.x.com/stream/sample10/accounts/:account_name/publishers/twitter/:stream_label.json?partition=1&backfillMinutes=5

참고:

• 연결 시 항상 ‘backfillMinutes=5’를 사용한 뒤 제공되는 중복 데이터를 처리하는 방법을 선택할 수 있습니다.

• 5분 이상 연결이 끊긴 경우 Recovery를 사용하여 데이터를 복구할 수 있습니다.

연결 끊김에서 복구하기

연결을 재시작하고 복구하는 과정은 다음 단계로 진행됩니다:

• 연결 끊김 시간 파악
  • 5분 이하인가요?
    • 스트림에 백필이 활성화되어 있다면, 적절한 ‘backfillMinutes’ 매개변수로 연결 요청을 준비하세요.
  • 5분을 초과하나요?
    • Recovery 스트림이 있다면, 끊긴 기간에 대해 Recovery 요청을 수행하세요(가능하면 현재 실시간 규칙 세트로, 필요 시 Rules API 사용).
• 새 연결을 요청하세요.

연결 끊김이나 다운타임이 발생했을 때 다음 전략으로 상황을 완화하고 복구할 수 있습니다:

1. 백필 구현 백필은 스트림 연결이 끊기기 이전 시점부터 재연결할 수 있게 하며, 최대 5분의 끊김을 보완합니다. 연결 요청에 매개변수를 포함해 구현합니다.

2. 다른 위치에서 이중화 스트림 소비 이중화 스트림을 동일한 실시간 환경으로 스트리밍해 데이터 중복 제거가 가능하다면, 기본 스트림과 이중화 스트림이 동시에 다운타임이나 끊김을 겪지 않는 한 복구가 필요 없습니다. 이중화 스트림을 프로덕션 환경에 실시간으로 스트리밍할 수 없다면 별도의 “비상” 데이터 저장소에 기록할 수 있습니다. 그런 다음 기본 스트림 연결에 끊김이나 다운타임이 발생하면 누락된 구간의 데이터를 기본 데이터베이스에 보충할 수 있습니다.

3. Recovery 구현 끊김이나 다운타임이 기본 스트림과 이중화 스트림 모두에 영향을 미치는 경우 Decahose Recovery를 사용해 누락된 데이터를 복구하세요. API는 보관 데이터에 대해 5일 롤링 윈도우를 제공하며, 한 번에 최대 1시간 분량씩 요청해 스트리밍하는 방식이 가장 효율적입니다. 이는 실시간 스트림과 병렬로 수행합니다. Recovery가 제공하는 5일 윈도우를 넘어선 Decahose 데이터 복구 솔루션은 없으므로, 중대한 다운타임에 대비해 이중화 스트림을 활용해 귀측에서 데이터를 완전하게 보관하는 것이 중요합니다.

비정상적인 저장 데이터 볼륨을 감지할 때— 연결 끊김이나 다운타임이 없었는데도 누락된 데이터를 감지하는 방법:

1. 게시물 수 집계 수집 앱의 최전단에서 수신한 원시 게시물 수를 집계하고, 그 수치와 최종 데이터 저장소에 도달한 게시물 수를 비교할 수 있어야 합니다. 차이를 모니터링해 수신 후 데이터가 누락되게 하는 문제를 팀에 알릴 수 있습니다.

2. 비정상 저장량 분석 최종 데이터베이스의 저장 데이터량을 분석해 비정상적인 감소를 탐지할 수도 있습니다. 이는 문제를 시사할 수 있지만, 경우에 따라 볼륨 감소가 정상인 상황도 있습니다(예: X 플랫폼 가용성 저하로 일정 기간 동안 사용자가 게시물을 생성하지 못하는 경우).

​

API 레퍼런스

​

Decahose 스트림

이 페이지에서 이동

메서드

인증

GET /{stream-type}/:stream

Replay API

​

메서드

메서드	설명
GET /{stream-type}/:stream	데이터 스트림에 연결합니다

​

인증

Volume Stream API에 대한 모든 요청은 HTTP 기본 인증을 사용해야 하며, 이는 console.gnip.com 계정에 로그인할 때 사용하는 유효한 이메일 주소와 비밀번호 조합으로 구성됩니다. 자격 증명은 각 요청의 Authorization 헤더로 전달되어야 합니다. 따라서 클라이언트가 모든 API 요청에 “Authorization: Basic” HTTP 헤더(HTTPS를 통한 인코딩된 자격 증명 포함)를 추가하는지 확인하십시오.

​

GET :stream

실시간 데이터가 전달되는 Firehose 스트림에 대한 지속 연결을 설정합니다.

​

요청 사양

요청 메서드	HTTP GET
연결 유형	Keep-Alive 요청 헤더에 이를 지정해야 합니다.
URL	대시보드의 스트림 API 도움말 페이지에서 다음 구조로 확인할 수 있습니다: Decahose: https://gnip-stream.x.com/stream/sample10/accounts/:account_name/publishers/twitter/:stream_label.json?partition=1
파티션(필수)	partition=\{#} - 전체 스트림을 수신하려면 이제 파티션이 필수입니다. 파티션 매개변수를 지정하여 스트림에 연결해야 합니다. 아래는 스트림별 파티션 수입니다: * Decahose: 파티션 2개
압축	Gzip. Gzip 압축으로 스트림에 연결하려면 연결 요청에 Accept-Encoding 헤더만 추가하면 됩니다. 헤더 예시는 다음과 같습니다: Accept-Encoding: gzip
문자 인코딩	UTF-8
응답 형식	JSON. 요청 헤더에 응답 형식으로 JSON을 지정해야 합니다.
요율 제한	60초당 요청 10회.
백필 매개변수	Backfill이 활성화된 스트림을 구매한 경우 이를 사용하려면 GET 요청에 “backfillMinutes” 매개변수를 추가해야 합니다.
읽기 타임아웃	클라이언트에 읽기 타임아웃을 설정하고 30초보다 큰 값으로 설정되어 있는지 확인하세요.
Tweet 편집 지원	모든 Tweet 객체에는 Tweet의 편집 내역을 설명하는 Tweet 편집 메타데이터가 포함됩니다. 자세한 내용은 “Edit Tweets” 기본 사항 페이지를 참조하세요.

​

응답

다음 응답은 해당 요청에 대해 API에서 반환될 수 있습니다. 대부분의 오류 코드는 본문에 추가 세부 정보가 담긴 문자열과 함께 반환됩니다. 200이 아닌 응답의 경우 클라이언트는 재연결을 시도해야 합니다.

Status	Text	Description
200	Success	연결이 정상적으로 열렸으며, 새 활동은 도착하는 대로 전송됩니다.
401	Unauthorized	잘못된 자격 증명으로 인해 HTTP 인증에 실패했습니다. 요청에서 자격 증명을 올바르게 사용 중인지 확인하려면 console.gnip.com에 로그인하세요.
406	Not Acceptable	일반적으로 스트림에서 gzip 인코딩을 수락하는 헤더를 클라이언트가 올바르게 포함하지 못했을 때 발생하지만, 다른 상황에서도 발생할 수 있습니다. 다음과 유사한 JSON 메시지가 포함됩니다: “This connection requires compression. To enable compression, send an ‘Accept-Encoding: gzip’ header in your request and be ready to uncompress the stream as it is read on the client end.”
429	Rate Limited	앱이 연결 요청 한도를 초과했습니다.
503	Service Unavailable	X 서버 문제입니다. 지수 백오프 패턴을 사용해 재연결하세요. 이 문제에 대한 공지가 X API Status Page에 게시되지 않았다면, 10분 후에도 연결할 수 없는 경우 지원팀 또는 긴급 지원에 문의하세요.

​

예시 cURL 요청

다음 예시 요청은 명령줄에서 cURL로 수행합니다. 또한 원하는 프로그래밍 언어로도 동일한 요청을 보낼 수 있습니다:

curl --compressed -v [e-mail] "https://gnip-stream.x.com/stream/firehose/accounts/:account\_name/publishers/twitter/:stream\_label.json?partition={#}"

​

Replay API

Replay API는 실시간 Volume 스트림을 보완하는 중요한 구성 요소입니다. Replay는 최근 X의 과거 데이터를 슬라이딩(롤링) 윈도우로 스트리밍 방식으로 제공하는 데이터 복구 도구입니다.