Twitter API＆OAuthと戯れる

Twitter API つーか OAuthと格闘

Twitter APIと遊ぶ機会があったので、もそもそと調べたり書いたりしてみました。OAuth部分の処理を書くのに少し時間がかかったり。既存品を使っても良かったのですが「その場の環境で動けば正義」というわけにもいかないので、処理を自分の制御下におくべく、OAuth部分の実装もゼロから書いてみました。

参考：APIアクセス権を委譲するプロトコル、OAuthを知る − ＠IT

そんときの調べごとをスピンアウト的にメモ

TwitterではOAuthでの認証を推奨？

むしろ、Basic認証はそのうち非推奨＆サポートしなくなるみたいですね。OAuthのほうがセキュアな気もしますけど、スパムにあっさり引っかかる人間の不注意がなくなるまではBasic認証のほうがセキュアじゃないんすか疑惑。

参考：Twitter APIのBASIC認証は2010年6月に「廃止予定」 - 頭ん中

APIの制限が150回ではない？

APIの回数制限がネックになるだろうなー、って思いましてAPIを叩ける回数について調べていました。したらば、公称の150回を超える回数で、回数制限対象のタイムライン系API( statuses/home_timeline.format, statuses/friends_timeline.format )を叩いていたら、150回を超えても一過性のタイムアウトを除いてちゃんと応答が返ってきている謎。

account/rate_limit_status という、現在の制限状態（残り回数とか制限がリセットされる時間とか）を教えてくれるAPIも並列で叩いてみたところ数字の推移が明らかにおかしいのです。

んで。

httpリクエストしてからレスポンスのヘッダーをとってみたら以下のような不思議な記述（抜粋）が。

string 'X-RateLimit-Limit: 450'
string 'X-RateLimit-Remaining: 306'

そしてその瞬間に account/rate_limit_status い問い合わせたところ

object(stdClass)[15]
  public 'reset_time' => string 'Tue Jan 12 12:23:27 +0000 2010'
  public 'remaining_hits' => int 102
  public 'hourly_limit' => int 150
  public 'reset_time_in_seconds' => int 1263299007

150回を超えてAPIを叩いてもちゃんと反応してくれたという事実を加味すると、どうも今の制限回数は公称値の3倍である450回に設定されているようです。remainingの値も、account/rate_limit_statusの値 3 = http_request_headerの値* で安定しているので裏付けとなっているでしょう。

補足的に下の記事も、自分の仮説を支持してくれているようなので、ひとまず450回の制限を軸に考えていきます。もちろん、途中で150回に戻る可能性も考えなければいけませんが。

参考：Twitter API の Rate Limit が一部緩和？ - trial and error

おまけ＠TwitterとOAuth用のphpをかいたので

業務的にはきっと、a-blog cmsの中の組み込みシステムとして吸収されてしまうので、まだ独立性を保っているうちにコア部分だけ単品ファイルにして用意してみます。もう処理は書けてるので、サンプルファイル作ったら公開してみますね。

今度、ソレを使ってa-blog cmsでつくるTwitter BOTの作り方でも書いてみましょうか。もっと実用的にTwitter連携のGETモジュールでも書けたらそれでいいかな。

おまけ2＠a-blog cms でつくる Twitter BOT

今使っているロリポとかcron（指定プログラムを指定スケジュールで実行するヤツ）がないので、GETモジュールとしてBOTプログラムを起動させたらいいんじゃないかな、と。

検索エンジンのクローラーがアクセスしてくれれば、最低限の回数ぐらいは起動してくれるはず。逆にアクセス過多な場合でも、キャッシュの残存時間を調整すればいいんじゃないかしら。

---