90の日記： 【和訳】Changes coming in Version 1.1 of the Twitter API【めどい】

Below is my rough translation of Changes coming in Version 1.1 of the Twitter API. For any corrections, recommendations, takedown requests, please comment in the comment section of this post.

Twitter API バージョン1.1での変更点

@sippey Michael Sippey
2012-08-16(木) 15:38

6月の終わり、一貫性のあるTwitterエクスペリエンスをお届けするためにわれわれがどういった努力をしているかについて、そしてこれから厳格になるTwitter API利用ガイドラインをどのように導入していくかについて書きました。これから、こんにちのTwitterエコシステムについての見通しを交えつつ来るべきAPIへの変更と移行計画についての情報、そしてなぜこれらの変更をしていくかについて書きます。

これから数週間のうちに、われわれはTwitter APIのバージョン1.1をリリースします。皆さんの将来的な計画のために、変更についていま、新版のAPIを公開する前にお伝えします。変更には

・すべてのAPIエンドポイントへの認証の必須化
・新しい、エンドポイントごとの流速規制方法
・Developer Rules of the Roadへの変更、特に伝統的なTwitterクライアントアプリケーションに関連して

を含みます。

Authentication Required

  現在、Twitter API 1.0において開発者は一部のAPIエンドポイントではアプリケーションが認証されていなくてもアクセスができ、Twitter APIを利用してわれわれに身分を明かすことなく公開情報を入手できます。例えば、われわれがIPアドレスしか把握していない、Twitter APIから大変に高い頻度でデータを引き出すアプリケーションが数多くあります(スクレイピング、botなど)。Twitter APIの不正利用を防ぎ、APIにアクセスするアプリケーションの種別を認識し、APIを開発者のニーズへあわせて進化せせていくために、Twitter APIとプラットフォームを使うアプリケーションの活動に可視性をもたせることが重要です。

  バージョン1.1では、APIへのあらゆるリクエストで認証が必須になります。すでにAPI利用時にOAuthを使っている開発者については、その認証トークンはシームレスにv1.0からv1.1へ移行します。もしあなたのアプリケーションがOAuthなしにTwitter APIを使っていれば、2013年3月までにアプリケーションを更新する必要があります。v1.0からv1.1への以降の時期については、下に詳細を記します。

Per-endpoint rate limiting

  現在、Twitter API バージョン1.0では一つのアプリケーションからの認証済みリクエストは、アプリケーションが要求する情報の種類にかかわらず一時間あたり350回に制限されています。この"フリーサイズ"手法では、アプリケーションが頻繁にリクエストを発行するエンドポイントへ多くのアクセスをわれわれから提供することに限りがあり、一方でTwitterの資源を乱用されることを防いできました。

  バージョン1.1では、エンドポイントごとの使用レート制限を提供します。一つのエンドポイントしか利用しないアプリケーションはさらに制限を受けますが、複数のエンドポイントを使うアプリケーションがレート制限を受けることは少なくなるでしょう。

  個々のAPIエンドポイントの多くはエンドポイントあたり60コール/時で制限されます。われわれのAPIの利用状況の解析結果からみて、このレート制限はTwitter APIに基づいて作られたアプリケーションの多くの要求を十分に上回り、同時にわれわれのシステムをアプリケーションの乱用から保護できます。

  Tweetの表示、プロフィールの表示、ユーザの表示、ユーザ検索に関しては大量アクセス用エンドポイント一式が用意され、アプリケーションからは最大でエンドポイントあたり720コール/時まで利用できます。

  エンドポイントによるレート制限についての完全なドキュメントはAPI v1.1と共にリリースされます。

Changes to the Developer Rules of the Road

  上で大まかに述べた機能的変更に加え、API v1.1の公開時にはDeveloper Rules of the Roadの変更も行います。変更には以下を含みます:

  -表示ガイドラインの表示要件への変更(Display Guidelines will be Display Requirements)
    Twitterユーザがいかなる場所でTweetを見たりTweetとインタラクトしても一貫性のあるエクスペリエンスを得られるよう、Twitter API v1.1でわれわれは表示ガイドライン(Display Guidelines)の提供から、モバイルにも導入される表示要件(Display Requirements)へ移行します。Tweetを表示するすべてのアプリケーションがこれらに従うことを要求します。表示要件には@usernameの適切なTwitterプロフィールへのリンク、適切なTweetアクションの表示(リツイート、返信、お気に入り)、デバイスに基づいた適切なツイートの拡大縮小などがあります。もしアプリケーションがツイートを表示し、われわれの表示要件に従わない場合、われわれはアプリケーションキーを無効化する権利を保持します。

  -プリインストールのクライアントへTwitterでの認証を必須化(Requiring pre-installed client applications to be certified by Twitter)
    v1.1において、われわれは携帯端末機、SIMカード、チップセットやその他コンシューマ電子機器にプリインストールされるクライアントアプリケーションを開発する開発者に、アプリケーションにTwitterによって認証(certify)しておくよう要求します。プリインストールのクライアントアプリケーションが"野に放たれ"た後、そのアップデートに要求される長いリードタイムのため、われわれは開発者がベストなTwitterエクスペリエンスを提供しているか、アプリケーションが出荷される前に確かめたいと思っています。もしTwitterによって認証されることなくアプリケーションをプリインストールして出荷した場合、われわれはあなたのアプリケーションキーを無効化する権利を保持します。

  -多数のユーザトークンを必要とする場合に、われわれとの共同作業を必須化(Requiring developers to work with us directly if you need a large amount of user tokens)
    過去数年に渡って我々が学んだ重要なことの一つに、開発者がだんだん多くのAPIコールを要求し始めたときは、ユーザと開発者のビジネスにとって価値ある領域へ開発者を導いてゆくことができるということがあります。そこにおいて、そして同業他社と同様に、もしあなたのアプリケーションが独立したユーザトークンを百万(one million)以上必要とすると考えるのであれば、われわれと直接に仕事を進めていただきます。

  くわえて、開発の対象がホームタイムライン、アカウント設定、ダイレクトメッセージAPIエンドポイント(典型的には伝統的クライアントアプリケーションが使用します)にアクセスするクライアントアプリケーションである場合、またはわれわれのUser Streams製品を使用する場合で、あなたのアプリケーションが100,000より多くの独立したユーザトークンを必要とする場合、われわれの許可が必要となります。

  これらエンドポイントを使用しており、すでにこれらのトークン数制限を超えているアプリケーションを停止させることはしません。あなたのアプリケーションが100,000個より多くのユーザトークンをすでに持っていれば、現在(本日)のトークン数の200%までは新規ユーザを追加できます。ユーザトークン数が200%に達した後は、そのアプリケーションを既存ユーザのために維持することはできますが、われわれの許可なしに更にユーザを追加することはできません。

  最後に、ここで述べているバージョン1.1での機能的変更を反映するためRules of the Roadにはさらなる変更が加えられる可能性があります。

  API v1.1 migration period
    API バージョン1.1のリリースと同時に、v1.0の非推奨化(deprecation)をアナウンスします。リリースの日から、開発者にはv1.0からv1.1へアプリケーションの移行を行うため6ヶ月が与えられます。すでにAPIに認証済みコールを使っている開発者については、この移行は比較的容易であり、APIエンドポイントの更新と新しいレート制限ポリシ下での挙動のテストのみを伴うはずです。認証を用いずにAPIにアクセスしている開発者については、アプリケーションがOAuthを用いるように更新する必要があります。

  Today's Twitter ecosystem
  こんにちのTwitterにおいては、広く深く種類のある個人開発者や企業がTwitter APIから得られるデータやコンテンツを用いてアプリケーションを製作しているのが見られます。大ざっぱに言って、われわれはこれらアプリケーションをそのオーディエンス(例: 消費者、あるいは企業)によって、またその核となる機能セット(例: ユーザをTweetと触れ合わせるものか、Tweetをデータ解析目的に使うか)によって分類します。

  われわれの新しいAPIガイドラインにおいて、われわれは上側左、下側左、下側右のの象限での活動を促し、右側上の象限を占める一部のユースケースを制限しようとしています。

(画像: https://dev.twitter.com/sites/default/files/images_blog/dev_chart.png)

  解説しましょう。

  グリッドの左側に入るのはビジネスを対象としたアプリケーションです。

    ・下側左の象限では、Twitterのコンテンツに基づいたビジネス向けの解析製品として使われるアプリケーションやサービスにおいて目覚しい発展が見られてきました。例を挙げると、Crimson Hexagonはブランド、メディア企業、政治キャンペーン向けの行動可能なレポート(actionable reports)を作成します。Topsyは金融、統治、ニュース、ブランドがニュースに反応するためのリアルタイム統計ダッシュボードを製作しました。DataMinrは金融産業向けに統計を提供します。

    ・上側左の象限にあるのは、企業のTwitterとの触れ合いを助けるソーシャルCRMプロバイダ、Sprinklr、HootSuite、Radian6(salesforce.comに買収されました) など、そしてテレビでの表示用にTweetを収集しフィルタするMass Relevanceなどのインテグレーション企業です。

  グリッドの右側に入るのは消費者向けのアプリケーションです。
    ・下側右の象限にはTwitterのコンテンツを社会影響力ランキングに利用するサービス、例えばKloutが入ります。
    ・上側右象限に入るのはユーザがTweetとふれあえるようにするサービス、StorifyやTweet発見サイトFavstar.fmなどが入ります。
    上側右象限にはまた、もちろんですが、TweetbotやEchofonのような"伝統的"Twitterクライアントも入ります。ほぼ18ヶ月前、われわれは開発者に、メインストリームのTwitterコンシューマクライアントエクスペエンスを真似たり、再現するアプリを作らないようにガイダンスを行いました。前回の記事から繰り返しになりますが、ガイダンスの内容は引き続き有効です。

  Looking Ahead
    API v1.1の向こうには、開発者の皆さんには単にTwitterのデータやコンテンツを使ってアプリケーションを作るだけでなく、インタラクティブなTwitter Cardsを作る新しい道を見越しています。

    twitter.com向けのTwitter Cardsを6月にアナウンス(そして7月にTwitter for iPhoneとTwitter for Androidをアナウンスして)以来、われわれは素晴らしい反応を得ています。400以上の開発者とパブリッシャがプログラムに参加し、拡張された(expanded)Tweetを通じてコンテンツを配布しています。次の数四半期に渡って、われわれは開発者に、コンテンツ・エクスペリエンスとアプリケーションを、Twitter Cardsを通じてTwitterに組み込んでいく新しい方法を提供していきます。最後に、われわれは現在、web開発者が容易にリアルタイムのTwitterコンテンツを自分のサイトに埋め込むことができるTwitter for Websites向けの新しい機能セットのために力を尽くしています。

  これらすべての情報によって、API v1.1でわれわれの向かう先がより明快に示せることを願っています。極めて近い将来、追加の、そして新しいプラットフォームの機能についてのニュースをお届けできると期待しています。