Twitter Streaming APIについてのメモ

ついにコレを試すときが！
REST APIについては今まで何度か使ってたけど、こっちは初。

わくわくですね。

Streaming API

REST APIと同じく、Developer登録すれば使えるようになります。

こっちからどういうものが欲しいかを決めて、そのエンドポイントへそれぞれリクエストして初めて結果が得られるRESTと違って、なんでもかんでも流しこまれるのがコチラ。

どんなデータが混じってくるのか、取得できるデータは下記リンク参照です。

参考：Streaming message types | Twitter Developers

そのほか、

レートのリミットがないので、利用出来るならREST APIより優先的に利用せよ
ただし、十分に帯域のある環境(モバイルは・・)で使いなさい
再接続の仕組みをしっかり組んだりしてください

などなどドキュメントは一回読んでおくべきですね。

大きく3種類あって、

Public streams
User streams
Sites streams

以下、お世話にならなさそうな順に。

User streams

単一ユーザーのTweets/Timelineを取得できるAPI。
個人的に使わなさそうなのであまり調べてません。

Site streams

Site Streams is currently in a limited beta. Access is restricted to whitelisted accounts.

というわけで、これも庶民には関係なさそう・・。

User streamsは単一ユーザー、こっちは複数ユーザーだそうな。

Public streams

Twitterの流れる全てのデータをいただけます。
そうそう、これこれ。

Public streams

これが使いたかったので、ここはきっちり調べます。

エンドポイントは以下3種類。

statuses/filter
statuses/sample
statuses/firehose

以下、またもお世話にならない順に。

statuses/firehose

Twitterの全タイムラインをリアルタイムに取得できるAPI。
というか、Twitterそのもの？

This endpoint requires special permission to access.

というわけで、一般人には縁のないAPIかな？
今はなきGoogleリアルタイム検索とかは、コレを使ってたそうな。

statuses/sample

Returns a small random sample of all public statuses.

上記のfirehoseの軽量版で、私たちでも使えます。
ただ、注意したいのがsmall random sampleとか書いてるけど、実際ぜんぜんsmallじゃないです。
Twitterの全Tweets規模からしたらsmallかもしれませんが、個人で扱うには十分すぎる量です。

試しにコールしてみてログ確認用のコンソールが大変なことになって焦りました。
Node.jsでやってたんですが、Ctrl+C入れても10秒くらい応答ナシになるくらい。

これを張りまくれば擬似的にfirehoseじゃね？っていうのはなくて、どこから繋いでも一緒の内容になるそうです。

statuses/filter

というわけで、お世話になりそうなのがこの方。
パラメータを何か絶対付与して、ふるいにかけたTweetsを取得するAPIです。

以下、オプション含め詳しく。

statuses/filterのオプション

以下は概要＋意訳なので、正式なものは以下リンクから。

参考：Streaming API request parameters | Twitter Developers

follow

ユーザーIDをカンマ区切りで指定すると、そのユーザーIDでフィルタができます。

track

これが一番使いそう。
フィルターにかけたいキーワードを設定できます。
これもカンマ区切り。

キーワードは60バイトまで
英語に関しては色々解釈に補完が入るがUTF-8の日本語とかはそのまんま
言うまでもないですが、カンマの後ろに半角スペースとかすると、そのまま通ります

locations

位置情報つきTweetsの場合、それらを指定した経緯で絞込んで取得できます。

delimited

delimited: 'length' として指定します。
そうすると、まず最初にTweetのバイト数だけがデータとして送られて、その後に本体が送られるようになります。
いまいち使いドコロがわかんない。

stall_warnings

stall_warnings: 'true' として指定。
Waningsをデータとして取得するかどうか。

count

This parameter requires elevated access to use.

というわけでスルー。
どうやら接続が切れて、再接続したときにどれくらい取りこぼしを防ぐかみたいな値ぽい。

with

with: 'user' もしくは with: 'followings'と指定。
User streamsかSite streamsを使用する際に指定するもので、そのユーザー単体か、フォロワーも含めるかの違いだそう。

replies

replies: 'all' と指定。
詳しくは書かないけども、相互フォローじゃない時のリプの扱い方が特殊らしく、そのふるまいに関するパラメータだそうです。

その他知っておきたい

過去は遡れない

あくまで「いま」どんなTweetがされているかをリアルタイムに取得するAPIなので、過去のTweetsは含まれません。
ニッチなワードとかで取得すると、まったく音沙汰なかったりもします。

複数接続できない

1つのアプリ登録につき、1接続しかできません。
複数接続しようとすると、古いのが切られます。

sampleかfilterか

何かを作る時に悩むのがココかなーと思います。
1接続しかできないとなると、最終的なフィルターはこちらでかけないといけないわけで。
そうなると母体となるサンプルは大いにこしたことがないんだけども、多すぎるのも非効率やし、うーん。

開発するときにどっちを使うべきか、どっちも試して決めなきゃですね。

おわりに

ざーっと知りたい場合は、以下の記事を。

参考：第3回Twitter API勉強会 - ストリーミングAPI #twtr_hack

とてもわかりやすく、正直いろいろ調べてこの記事を書く前に読みたかった・・。

今度は実際になんか作ってみての記事を書きますです。