Twitter API が v1.1 になったから Overview を訳してみた

Current status: API v1.1 | Twitter Developers
結構早かったですね。
Overview: Version 1.1 of the Twitter API | Twitter Developersを意訳しました。

Twitter API v1.1はローンチ以来、初めてのAPIアップデートです。
我々はそれが開発者にとって何を意味するのか興奮しているし、
ここにすべての意味のある変更を補足したので
どんな小さなことも見逃さないでください。

1. 改良されたレートリミット
2. JSONのみのサポート
3. すべてのエンドポイントで認証は必須
4. 開発者ルールのアップデート
5. 開発者ディスプレイ要件
6. 新しいTwitterクライアントポリシー
7. entities と retweets のデフォルト化
8. API v1.0 の廃止
9. dev.twitter.com のアップデート
10. フィードバックと次のステップ

改良されたレートリミット

我々は、エンドポイント毎に15分のスパンにレートリミットのウインドウ(?)を分割して、
ほとんどの個々の呼び出しはそれぞれのウインドウで15リクエストを可能にしている。
(訳注※ほとんどの API は15分に15回のリクエストが可能)
ほとんどの場合、あなたは以前より多くのエンドポイント毎の API 呼び出しができるでしょう。
他の幅広く使われている API は、ウインドウ毎に 180 回の呼び出しができます。
これは GET statuses/show/:id, GET users/lookup, GET search/tweets や他の呼び出しを
行うアプリケーションに特に有利になります。
API v1.1のレートリミットのドキュメントを読むだけでなく、
ここで各エンドポイントごとのレートリミットを確認してください。

JSONのみのサポート

API v1.1 は JSON のみをサポートします。
我々は、まずストリーミング API 、より最近にトレンド API の XML サポートをやめ、
しばらくのあいだ、これをほのめかしてきました。
我々は、プラットフォーム間で共有される JSON フォーマットを支持することを選びました。
したがって、我々は今日使われるのは稀な XML, Atom, RSS のサポートを中止することを決定しました。
歴史的な文脈のため、我々が API を構築した時に、すべての主要な言語は
JSON をサポートする高性能な、よく銀にされたライブラリを持っていませんでした。
しかし、今日ではそれを持っています。

すべてのエンドポイントで認証は必須

v1.1では、我々はアプリケーションにすべてのリクエストは OAuth 1.0a で認証することを要求している。
現在、この(Twitterにとっての)可視性は(Twitterに対する)虐待的な行為を防止できるだけでなく、
アプリケーションのカテゴリによってどのような API を使っているのかを一層理解するのに役立ちます。
より開発者のニーズを満たせるようにその理解を利用して、我々はプラットフォームを進化させ続けます。
この時点で、すべての認証はユーザーのコンテキストを必要としますが、
今後数週間のうちにユーザーのコンテキストを必要としない認証のフォームのサポートを出します。

開発者ルールのアップデート

我々は開発者ルールをアップデートました。
また、あなたが知っておくべき最も重要なポリシーのコンセプトの概要を作成しました。

開発者ディスプレイ要件

我々の以前のディスプレイガイドラインは更新され、現在のディスプレイ要件だと考えられています。
あなたがWebやモバイルのコンテキストでツイートやタイムラインをレンダリングしている場合は
これらの新しいDeveloper Display Requirementsを確認したいと思う。
(訳注※よくわからないけど読んどけよーくらい？ガチガチに強制しているようではない？)

新しいTwitterクライアントポリシー

コアの Twitter 体験を再現するすべてのアプリケーションは、通常"クライアント"と呼ばれ、
10万ユーザートークン制限を含む、いくつかの新しい制限がかけられることになります。
明確にするために、10万ユーザートークン制限はコアの Twitter 体験を複製する少数のクライアントに
適用され、より広いエコシステムの他のアプリケーションの大部分には適用されません。
これらの新しい条項は、我々の更新されたDeveloper Rules of the Roadで詳細に説明されています。

entities と retweets のデフォルト化

該当する場合には、entities やリツイートは現在の v1.1 でデフォルトで返されます。
include_entities が false にされていない限り、Entities が Tweet オブジェクトの一部として返されます。
include_rts が false にされていない限り、公式リツイートがタイムラインに含まれることになります。

API v1.0 の廃止

ほとんどの開発者は v1.0 から v1.1 への移行ですべきことはほとんど何もありませんが、
我々は移行作業をする十分な時間があることを確認したい。
我々は v1.0 をオフにする前に6ヶ月の猶予を提供する予定です。
2013年3月5日以降、v1.0 のエンドポイントは使用できなくなります。

dev.twitter.com のアップデート

dev.twitter.comのドキュメントは API v1.1 での最新の変更と利用可能なメソッドを反映しています。
あなたが v1.0 と v1.1 のどちらのドキュメントを閲覧しているかより区別しやすくするために
各エンドポイントのドキュメントの上にバージョンを示す新しい青い錠剤に気づくでしょう。

フィードバックと次のステップ

あなたが API の新しいバージョンで問題を発見した場合、
気づいたことを報告するために Issue Tracker を使ってください。
最後に、我々は最も一般的な質問に答えるために、v1.1 に関するFAQを作成しました。
あなたがそこで答えを見つけられなかった場合は、
常に我々が利用でき、あなたのフィードバックのすべてをアクティブに聞くことのできる
API v1.1 専用のディスカッションスレッドにいつもポストできます。
我々は v1.1 への進化の過程を通してあなたと働くことを楽しみにしていて、
みんなが構築するものを見るために待つことができない。

今何かと叩かれてる感じあるけど期待してる。

Twitter API v1.1 変更点まとめ

2012/08/17(金)にTwitter API v1.1についてTwitter開発ブログの記事などが公開されました。
Changes coming in Version 1.1 of the Twitter API | Twitter Developers
Twitterブログ: Twitter API v1.1でのAPI利用ルールの変更について
誤解した人が多かったのか悲観的な声をよく聞いたような気がします。
誤解のないようにまとめておきたいと思います。間違いのないように努めますが本家の情報も見ておいたほうがいいと思います。

大きな変更点は3つ

1. 全てのAPIエンドポイントに認証が必要になる
2. 新しいエンドポイント毎のレートリミット方式
3. デベロッパールールの変更(特に従来のTwitterクライアントのアプリ周り)

※エンドポイント: 簡単に言えばAPIの種類…だと思います。

1.認証が必須に

今までTwitter APIにはSearch APIなど認証が必要でないものがありましたが
v1.1からは全APIエンドポイントが認証必須になります。
認証なしのAPIは誰にでも使えていましたが、
そのため非常に高いレートでAPIを叩くなどAPIの不正利用があったようです。
それを防止し、開発者のニーズを満たすよう進化するためには
どのようなAPIにアクセスしてるかを明確にすることが重要なため認証が必要だそうです。

既にOAuthを使用している開発者のために認証トークンはv1.1への移行でもシームレスに引き継がれます。
認証の必要のないAPIを使用している場合は2013年3月前までにOAuth認証するように更新が必要になります。

2.エンドポイント毎のレートリミット

TwitterのREST APIは現在APIの種類に関係なく350回/時でしたが、v1.1ではエンドポイント毎に60回/時になります。
数字上減ったように見えますが、APIエンドポイント(種類)毎のレートリミットになっているため
ツイートしすぎてふぁぼれないということなどがないので改良だと思います。
60回/時はTwitter APIの利用状況を分析して設定されたもので、ほとんどのアプリケーションのニースを超えるそうです。

また、ツイート表示、プロフィール表示、ユーザーの検索などの大量のエンドポイントを必要とするアプリケーションは
720回/時までのレートリミットが適用されるようです。
詳しくはv1.1のリリースで公開されるドキュメントに記載されるようです。

3.デベロッパールールの変更

1. Display Guidelinesが表示の必要条件に
2. プリインストールのクライアントアプリケーションはTwitterによる認定が必要に
3. 大量のユーザートークンを必要とする場合は開発者は直接Twitterに連絡が必要に

3-1.Display Guidelinesを守る

ツイートについて同一のユーザー体験(@usernameをクリックしたらプロフィールが表示されるなど)が大切だということです。
まともな開発者ならユーザーが期待する動作を作ると思うので問題ないでしょう。

3-2.プリインストールのクライアントアプリケーションはTwitterによる認定が必要

モバイルデバイスやSIMカード、チップセットなどにプリインストールするの場合は、Twitterの承認が必要となります。

3-3.大量のユーザートークンを必要とする場合は開発者は直接Twitterに連絡が必要に

One of the key things we've learned over the past few years is that when developers begin to demand an increasingly high volume of API calls, we can guide them toward areas of value for users and their businesses.

ちょっと意味が良くかわからなかったんだけども連絡してくれたら良い感じにしてくれるのでしょうか。
ユーザートークン数が10万になったら許可が必要になるようです。
もう既に10万ユーザーに達している場合は現在のユーザートークン数の200%までの増加が認められています。
それに達した場合もTwitterに許可が必要になります。

詳しいことが書かれていないので連絡をとったら許可が貰えるのかなどはよくわかりません。
取らぬ狸の皮算用で騒いでも仕方ないので詳しい情報が出るまで静観しておくのが良さそうです。

Twitter API v1.1への移行期間

v1.1がリリースされると同時にv1.0の廃止がアナウンスされます。
リリース後6ヶ月は移行期間となります。
OAuth認証が必須になるので認証するようにアップデートし、
新しいレートリミットでのアプリケーションの挙動をテストするだけの比較的簡単な移行になるでしょう。

今日のTwitterのエコシステム

今回のAPIの変更は左上、左下、右下の活動を推奨し、右上の特定のユースケースの制限をしようとするものです。

右上にはツイートキュレーションサービスやツイート発見サイトfavstar.fmなどがありますが、
制限の対象となるのは単に模倣や再現をした従来のツイッタークライアントのようです。
18ヶ月前にもアナウンスしているようですし、新しい価値を提供できないTwitterクライアントはもういらないということでしょう。

近く、v1.1に関する追加情報があるようですのでTwitter開発者ブログをチェックしておいた方が良さそうです。

おまけ

Twitter API ポケットリファレンス (POCKET REFERENCE)
今回のAPIのバージョンアップはそれほど影響のあるものではないので
Twitter API ポケットリファレンスはまだまだ使えそうです！
Twitter APIを叩くなら持っておきたいですね。

[Twitter][API]改訂で2012年5月14日までに開発者がするべきこと

0.まずTwitter API ポケットリファレンスを買います

以下の該当する項目を修正する

Twitter APIの改訂 - 2012年5月14日 - Google グループ
# https://dev.twitter.com/blog/api-housekeeping の抄訳です
...
1. バージョン抜き、サブドメイン抜きのAPIエンドポイントはサポートされなくなる
例)
http://twitter.com/statuses/user_timeline.xml
のかわりに今後は
https://api.twitter.com/1/statuses/user_timeline.xml
を使用(httpはサポートされますが、httpsの利用を推奨しています)

またOAuth関連も同様 http://twitter.com ではなくhttps://api.twitter.com/oauth/* を利用してください

2. 非推奨としてアナウンスされてきたエンドポイントは廃止
非推奨(廃止される)エンドポイントのリストは以下のページにあります。
https://dev.twitter.com/docs/deprecations/spring-2012
特に古くからあった statuses/public_timeline も廃止されることに注意してください。
public_timelineのかわりにはストリーミングAPIの sample.json を使えます。

3. Atomは廃止
Atomはほとんど利用されていません。RSSのサポートは継続します。

4. ツイートエンティティをサポートするエンドポイントはinclude_entitiesパラメータの有無に関わらずエンティティを返す

5. since_idやmax_idをサポートするエンドポイントはpageパラメータによるページングを廃止

6.REST API Resources | Twitter DevelopersのDeprecatedをチェックする

Twitter API ポケットリファレンスを持っていれば、
将来的に include_entities と include_rts は
常に含むようになると書いてあるのでうろたえることはない。
本のサンプルはJSONの取得だからAtom廃止は関係ない。

出版されてからのAPI変更はハマると怖いのでメモ。
retweet_count が100以上で100+と返ってくるというのが、
API改訂で数値で返ってくるようになったのは把握している。
他は良くわからないのでTwitter API ポケットリファレンスも
改訂版が出ると良いですね。現状でもほとんど正確ですが。

今使ってますが凄く役に立っています！！！！
山本 裕介 @yusukey さん ありがとうございます！！！