twitterのstreaming API

新年になったので、少しずつここの内容も色を変えていくこともあるかもしれない。今日はのんびりとtwitter streaming APIを眺めていた。

streaming APIは、特定のクエリに対する更新情報を随時流しっぱなしにする、いわゆるpush配信の技術で、ユーザはHTTPリクエストを送って、随時流れてくるレスポンスを受信しつづけるだけだ。cometと同じようなもので、一定期間に返すものがなければ、クライアント側に空っぽの内容を返し、接続を維持する。ある種のHTTPクライアントは、サーバとのTCP接続を切断した後にユーザにレスポンス内容を返したりするので、この用途に使えなかったりする（と書いてある）のだけど、変に内部キャッシュに貯め込まない実装なら問題無く使えるだろう。

似たような技術ではpubsubhubbubというものがあって（これはもともとiGoogleガジェットでも使われているpubsubというXMPPのひとつの応用を、さらにHTTPにもってきたようなアプリケーションプロトコル）、データソースが全てtwitterであることや、細かいクエリパラメータを渡してフィルタリングできたりJSONで返せたりすること以外は、概ねstreaming APIとやっていることは変わらないだろう。

streaming APIでは、何でもほしいものをストリーミングで拾ってこられるわけではない。アカウントに紐付けられたアクセスレベルによって、実現可能なクエリは変わってくるようだ。APIドキュメントでは、filter, firehose, retweet, sample というクエリが説明されている。twythonのstreaming.pyには、APIドキュメントでも言及だけされているshadowやらbirddogやらが含まれている（URIの形式が違うようなので、これが動作するものなのかどうかは分からない）。firehoseを使えば、public_timelineのようなものが取得できるようだけど、標準のアクセスレベルでは取得できないようだ。sampleは、その一部をランダムに取り出しているようで、通常のユーザなら誰でもアクセスできるようだ（一般に開放しても困らない程度の量になっているということだろう）。

有償契約によって付与されるであろうアクセスレベルによって高度なクエリを可能にするというのは、収益を上げるためのひとつの上手い方法に見える。

streaming APIの恩恵をもっとも受けやすいのは、おそらくTweetBubblesのようにsearch APIを使って定期的にハッシュタグなどを探すタイプのアプリケーションだろう。もっとも、pull型で実装されたコードベースがある場合、基本的にbest effort型で不安定なpush型ベースに書き換えるのは面倒かもしれない。あとは、TwitterIrcGatewayみたいなものは、よりリアルタイムに近づけることもできるだろう。リアルタイム性が多かれ少なかれ求められるアプリケーションでなければ、無理に対応するものではないと思うけど（コードのあり方がだいぶ変わるはず）、楽しい使い方があるものかもしれない。