twitter api 1.1 变化

REST API

REST APIはTwitter APIの一番伝統的で中核となるAPI群です。これまでREST APIを呼び出す際のエンドポイントURLは「http(s)://api.twitter.com/1/*」でしたが、Twitter API 1.1では「http(s)://api.twitter.com/1.1/*」となります。

　多くのAPIはエンドポイントURLが変わるだけですが、一部廃止・変更もあるので、注意が必要です。公式ドキュメントに廃止・変更になるAPIのリストがないので、以下にまとめました。

　なお、廃止対象に挙げているAPIでもAPI 1.1のエンドポイントで実際呼び出せてしまうものがいくつかありますが、ドキュメントには記載されておらず、今後呼び出せなくなる可能性がありますので使うべきではないでしょう。

• 廃止になるAPI（废弃的）

　　/statuses/retweeted_by_me
　　/statuses/retweeted_to_me
　　/statuses/retweets_of_me
　　/statuses/retweeted_to_user
　　/statuses/retweeted_by_user
　　/statuses/:id/retweeted_by
　　/statuses/:id/retweeted_by/ids
　　/friendships/exists
　　/friendships/no_retweet_ids
　　/account/totals
　　/notifications/follow
　　/notifications/leave
　　/trends/daily
　　/trends/weekly
　　/blocks/blocking
　　/help/test

• 変更になるAPI（有变更的api）

　　/blocks/blocking/ids → /blocks/ids
　　/direct_messages/destroy/:id.json → /direct_messages/destroy.json?id=:id
　　/favorites/create/:id.json → /favorites/create.json?id=:id
　　/favorites/destroy/:id.json → /favorites/destroy.json?id=:id
　　/account/rate_limit_status.json → /application/rate_limit_status.json
　　/lists.json → /lists/list.json

Twitter API 1.1では全てOAuthが必須となります。

検索APIの変更点

従来検索API呼び出し用のエンドポイントは「http://search.twitter.com/search.json」でしたが、API 1.1ではREST APIと統合され、「https://api.twitter.com/1.1/search/tweets.json」となります。

　また、従来検索APIのレスポンスの構造はREST APIのレスポンスと異なっていましたが、API 1.1で統一されることになります。つまり、呼び出しエンドポイントを書き換えるだけではなく、レスポンスをパースする部分についても、コードの改修が必要になります。

　レートリミットについては、これまでIPアドレス単位であったのが、REST APIと同じくアカウント単位となります。他のサービスとIPアドレスを共有しているクラウドにデプロイしたアプリケーションが予測できないタイミングでレートリミットに達してしまうようなことはなくなります。

検索API変更のポイント

• エンドポイントURLが変更
• レスポンスの構造がREST APIと統一
• レートリミットはIPアドレス単位ではなくアカウント単位へ

【3】レートリミットの変更点

　Twitter APIを利用する上で忘れてはならないのがレートリミットです。従来REST APIのレートリミットはOAuthなしの場合はIPアドレス当たり1時間150回、OAuthありの場合は1アカウント当たり1時間350回でした。

　API 1.1では、1アカウント当たり15分で“エンドポイントごとに”15回または180回となります。単純に1時間当たりにならすと、60回または720回になるので、多数のエンドポイントを利用するアプリケーションにとっては350回以上呼び出せることになります。よって実質、制限が緩くなったことになります。

　しかし、特定のエンドポイントを集中的に呼び出すようなアプリケーションにとっては幾分制限が厳しくなります。レートリミットにシビアなアプリケーションでは、呼び出せる残り回数をX-Rate-Limit-Remainingヘッダで、また呼び出しカウントがリセットされる時間をX-Rate-Limit-Resetヘッダで確認するようにしましょう。従来のX-RateLimit-*と違いRateとLimitの間にハイフンが入っていることに注意してください（参考：公式ドキュメントの「レートリミットの詳細（英語）」）。

　各エンドポイントの実際のリミットについては公式ドキュメント「エンドポイントごとの15分当たりのリミット（英語）」をご参照ください。

　1日1アカウント当たりツイート1000件、ダイレクトメッセージ250件といった更新系のAPI、またストリーミングAPIの制限については変更ありません。

レートリミット変更のポイント

• リミットはアカウント単位ではなくエンドポイント単位
• アプリケーションにより、制限が緩くなる場合と厳しくなる場合とある
• ツイート数、DM数については変更なし

【4】アプリケーション当たりのユーザー数

　今回初めて導入されたのが「アプリケーション当たりのユーザー数」という制限です。ここでいう「アプリケーション」はTwitter APIに接続するサービスやアプリごとにdev.twitter.comで登録するものを指しており、1クライアントアプリケーション当たり10万ユーザーが限度となりました。それ以上の数のユーザーが利用するには、個別にTwitterの許可が必要です。

　今回のAPI／規約改定において、後述の「Display Requirements」と併せて、とりわけ大きく話題になっており、また開発者の離反を招く原因ともなっています。

　ただし、このユーザー数の制限は「クライアントアプリケーション」にのみ適用されるもので、単にTwitterと連携するサービスやアプリケーションは関係ありません。いわゆる「Twitterクライアント」を新規に開発するのでなければ気にする必要はないでしょう。

　また、すでに10万ユーザーを超えているクライアントアプリケーションについては現ユーザー数の倍まで許容されるとのことです。実質的には既存ユーザーには影響を与えずに新規のクライアントアプリケーションの開発を抑止するための施策と見てよさそうです。

　そもそもTwitterは1年半以上前、開発者向けにクライアントアプリケーションの開発ではなくTwitterが提供していない領域のサービスの開発を推奨する旨の声明を出しています（参考：「Twitter Development Talk > consistency and ecosystem opportunities」）。

　趣味や習作であれば問題ありませんが、今後ビジネスとして新規にTwitterクライアントアプリケーションを開発するのは賢明ではなさそうです。どれだけ努力をしても安全に到達できるユーザー数は10万であり、それ以上のユーザー数を獲得するのがTwitterによって許可されるのかどうかは不明だからです。

【5】ツイート、タイムライン表示方式の厳格化

　Twitterは従来よりAPIを通じて取得したコンテンツを「Display Guidelines」で決められたフォーマットに従って表示するよう開発者に要請してきました。これまでは「ガイドライン」であり、その適用を強制することはありませんでした。

　今回からガイドラインは「Display Requirements」と改められ、アプリケーションはこのフォーマットに従ってツイートなどを表示する必要があります。技術的に対応できない場合は、個別に問い合わせて許可を得る必要があるとしており、かなり厳密に適用を求める姿勢のようです。

　規定の内容はかなり細かく、例えば「山本裕介 @yusuke」のように@ユーザー名よりも前（または上）に名前を表示すること、ツイートのタイムスタンプが24時間以内であれば相対時刻で表示すること、ツイートのアイコンを左側に必ず表示することなどが決められています。詳しくは、公式ドキュメント「Developer Display Requirements」をご覧ください。

　Webサイトに数個のツイートを張り付ける程度であればTwitterの「このツイートをサイトに埋め込む」機能より取得したHTMLを利用すると良いでしょう。

図　ツイートの埋め込み機能

冷静に情報の情報の真贋を見極めよう

　Twitter APIは柔軟性と自由度の高さから人気があるだけに、いくらかの制約を加える今回の仕様・規約変更はセンセーショナルに受け止められています。しかしTwitterの主張するユーザー体験の統一や、一部の過負荷なアプリケーションの抑制といった目的からは理にかなった変更ともいえるでしょう。

　要点さえ押さえれば、今回の変更に対応するのは難しいことではありません。年々存在感を増しているプラットフォームですから、その強みを生かして今後もAPIを活用してはいかがでしょうか？

　また、今回の騒動に連動してTwitter関連の話題はことさら拡散しやすい状態にあります。中には憶測にすぎない記事も確定事項であるかのように大きく取り上げられていることすらあります。

　Twitter連携アプリケーションを開発・検討している開発者の方はいつも以上に冷静になって、情報の真贋を見極める必要があります。Twitterと連携するビジネスを展開する場合は日ごろから、公式ドキュメント、ブログや掲示板、非公式ですが、Twitter API日本語メーリングリストをチェックしておくと良いでしょう。