驚くべきは、呟遞

ヒヒのドロップ率下振れが續き頭のをかしくなつた騎空士はtwitterの救援IDを拾ふアプリを試作することにしたのだが、驚くべき事態に直面したのでその記錄。

前提としてTwitterのAPIにはv1.1とv2の2つがある。一般に番號が大きい方が新しいと云ふ慣例に外れず、twitterもv2の方のAPIが新しい。本邦では新しいものの方が無條件に良いと云ふ風潮があるが、TwitterのAPIに限つてはさうではないやうである。v2のAPIを使つてtwitterの救援IDを拾ふと、檢索、ストリーミング檢索共にラグが10秒は生じるのだが、巷に存在する救援IDを垂流すサイトではこゝまで長い遲延はないどころか0秒と表示してゐるところまである。そしてこれらのサイトは比較的昔からあることに加へ、オープンソースのものはコードを輕く、さうでなくとも作者のツイートを見ればv1.1のストリーミング檢索APIを使つてゐることが容易に想定される。

ところで今新たにTwitterのAPIを利用する場合にはそのまゝではv2しか利用できず、v1.1を使はうとすれば英文で利用目的の申請が必要だつたりと手間が多い。しかしながらこゝで手を拔いてしまつては壓倒的な遲延で差をつけられてしまふので、本當にv1.1とv2で遲延に差が出るのかを調べてみることにした。申請理由には救援IDを遲延ナシで取れるかを調べるためと赤裸々に書いてまで試した結果は惨憺たるものであつた。なんと今年の4月末より後に作られたアプリではv1.1のAPIの內、ストリーミング檢索APIは利用することはできないと云ふではないか。今は當然5月であるから、わざわざ申請してv1.1を使へるやうにする意味はなかつたことになる。そんなことも知らずに書いた申請文言が實に馬鹿みたいである。ちなみにたゞの檢索APIは使ふことが出來たので叩いてみたが、遲延は1秒程であつた。v2とv1.1の差は歷然たるものである。

ところで何故このやうな事態になつてゐるかと云へば、twitter社はv1.1のストリーミング檢索APIの廢止を目論んでゐるからである。今年の10月末から6ヶ月かけてこのAPIは新しく作られたアプリに限らず利用ができなくなるとのことなので、既存の救援IDを流してゐるサイトへの影響も避けられないやうに思ふが、これらのサイトはどのやうな對應をするのだらうか。このまゝ行けば數年後にはすべてのサイトが足竝み揃へて遲延10秒以上となる可能性もなくはない。或いはv1.1の檢索APIを叩くタイミングを工夫してやりくりすればもう少しはなんとかなるかもしれないが。もう少し資料を漁れば有料APIを用ゐればより高度なストリーミング檢索ができるらしいので、もしそちらの方のAPIでは遲延がないのだとすれば、twitter社としてはv1.1時代の如くラグなくツイートをリアルタイムに檢索するならば相應の利用料を拂つてくれと云ふことなのかもしれない。しかしそのAPIは法人でないと取れないと云ふ話もあるやうだし、個人で何かをやるには中々大變な時代になつたものだ。

追記：これは遲延ナシの速さは有料APIに求めるべきとかさう云つた問題ではないかもしれない。twitter社によるとv2の檢索APIは10秒の遲延を入れることで、その間にメタデータの差込みや一貫性の維持のための處理を行なつてゐるらしい。從つてこの遲延はAPI品質を保つための仕樣であり、とするならばどう足搔いても遲延1秒程度のv1時代の檢索結果は得られないと云ふことになりさうでもある（有料APIの細かい仕樣までは調べてないのでなんとも言へないところはあるが）。