Twitter REST API の使い方

自動化された Web 2.0 のための Twitter REST API を探る

Twitter は間違いなく、最近 World Wide Web に登場したソーシャル・ネットワーキングのなかで最も成功している例の 1 つです。Twitter には、Web 開発者が Twitter サイトで提供する各種機能へのユーザーのアクセスを可能にするための API が用意されています。この記事を読んで、Twitter REST API の基本的な使い方を学んでください。

Brian M. Carey, Information Systems Consultant, Triangle Information Solutions

Photo of Brian CareyBrian Carey は、Java エンタープライズ・アプリケーションのアーキテクチャー、設計、実装を専門とする情報システムのコンサルタントです。Brian は Twitter でつぶやきを公開しているので、彼をフォローすることができます (http://twitter.com/brianmcarey)。



2009年 6月 09日

Twitter は、140 文字以内で自分が今何をしているのかを特定の人々に知らせるための Web ベースの手段です。

以上は Twitter の短い定義です。

Twitter を詳細に定義しようとすると多少込み入ってきますが、検討する価値はあります。Twitter は、業界がソーシャル・メディア、オンライン・ソーシャル・ネットワーキング、あるいは Web 2.0 と呼んでいる世界のなかで最も成功しているサービスの 1 つです。Twitter のユーザーは、フォロワーをたくさん集め、時々自分が何をしているのかをフォロワーに伝えるために Twitter の GUI に短い文 (Twitter の世界では、「つぶやき」と呼ばれています) を入力してボタンをクリックします。すると、つぶやきがフォロワー全員に送信されます。フォロワーはそのつぶやきを読むことも、賛同して応答することも、あるいは無視することもできます。

よく使われる頭字語

  • API: Application Programming Interface
  • GUI: Graphical User Interface
  • HTTP: Hypertext Transfer Protocol
  • IP: Internet Protocol
  • REST: Representational State Transfer
  • RSS: Really Simple Syndication
  • URL: Uniform Resource Location
  • XML: Extensible Markup Language

シェイクスピアの作品に「簡潔は機知の精髄 (Brevity is the soul of wit.)」という一節があります。Twitter の発案者はこの哲学を実践し、つぶやきを最大 140 文字に制限しています。実際には、この文字数制限はシェイクスピアとは何の関係もなく、単に Twitter が開発された当時のモバイル・デバイスの制約によるものです。しかし、これによって 1 件のつぶやきに不要なスパムや長々とした言葉の羅列を入れられなくなるため、歓迎すべき制限となっています。

つぶやきの長さは厳しく制限されるものの、実際のつぶやきの内容には、それほど厳しい制限はありません。Twitter の当初の意図は、自分が今何をしているかをフォロワーに伝えることでした。言うまでもないことですが、毎日何百万件も投稿されるつぶやきの話題が常に、自分が今何をしているかについてであるというわけではありません。意見やニュース、そして自分のブログへのリンクや他の人のブログへのリンクなどを投稿する人もいます。したがって、新たに Twitter に参加するユーザーは、つぶやきの投稿者が今していることとはまったく関係のないつぶやきを受信することを覚悟しておく必要があります。

Twitter には、すべてではないにしても大抵の Web 2.0 に付き物のもう 1 つの利点があります。それは、無料だということです。まさにその言葉通り、Twitter に参加するにも、誰かをフォローするにもコストはかかりません。フォロワーを何人持とうと料金が発生することはなく、もちろんつぶやきを投稿するのも無料です。Twitter はまさに、人々に利用してもらうために存在しています。

ここまでで、Twitter とは何であり、何をするためのものか、その大まかな概要をつかめたことと思います。Twitter サイトにまだアクセスしたことがない方は、ここから先を読む前に Twitter サイトにアクセスしてみてください。一度アクセスすると、REST API についてずっと簡単に理解できるようになります。

Twitter REST API

基礎をおさえたところで、ここからは Web アプリケーション開発者にとって面白い部分に移ります。Twitter はソーシャル・メディアの分野で役立つツールというだけでなく、開発者に Twitter の機能を自動化するための包括的なサービスを提供します。これらのサービスのうちの 1 つが (そして、おそらく最もよく使われているのが)、REST API です。

REST とは Representational State Transfer の頭辞語です。この記事では、正確な REST の定義についての詳細な説明は行いませんので、IBM® developerWorks® の他のページを調べてください (「参考文献」を参照)。ここで取り上げる話題で REST に関して必要な知識は、REST を利用することで開発者が単純な HTTP 呼び出しで情報とリソースにアクセスできるようになるということだけです。

一例として、FishinHole.com という会社が、顧客に釣具を販売する Web サイトを運営しているとします。ユーザーはこの会社のサイトにアクセスして、各種のルアー、リール、ロッドなどを表示することができます。その方法は昔ながらのリンクをクリックするというものです。この方法で、FishinHole.com ではユーザーがサービスを利用できるようにしています。

その一方で FishinHole.com では、釣具のカタログを REST によって公開することで、他の Web アプリケーションがそのサービスを利用できるようにもしています。この場合、Web アプリケーションはクリックという手段ではなく、単純な HTTP 呼び出しを実行することによってルアー、ルール、ロッドなどに関する情報を取得します。例えば、http://www.fishinhole.com/catalog/rest/lures?format=xml を呼び出すと、この会社が提供するすべてのルアーのリストが XML フォーマットで返されます。また、http://www.fishinhole.com/catalog/rest/item?id=343221 を呼び出した場合には、商品番号 343221 に関する情報がデフォルトのフォーマットで返されます。

REST はいわば、特定のロケーションの URL を指定するだけでドメイン固有のデータを取得できる手段であると考えてください。この記事での REST の用途は、まさにこれに尽きます。また、REST を単純化された Web サービスとみなすこともできますが、この見方をある特定の人々の前で声高に言ったとすると、論争の真っ只中に置かれることになるかもしれません。

注: 念のため言っておきますが、FishinHole.com は実在しません。そのため、上記のいずれかの URL をブラウザーに貼り付けてアクセスしようとすると、エラーを受け取ることになりますが、これは当然のことです。上記の URL は、典型的な REST 呼び出しのフォーマットを示す例として記載しているだけです。

完全に機能する REST API の例を見てみたいと思いませんか?実際に URL をブラウザーに貼り付けて、何か意味のあるものを表示させるには、この先を読んでください。


開始手順: 単純なサンプル

たった今、Joel Comm の傑作本『Twitter Power』を読み終えたあなたは、今すぐ Twitter を使った積極的なオンライン・マーケティング・プログラムで経済的な自立への道を歩き出すことを決心しました。

その一方で、あなたは優れたソフトウェア開発者でもあります。つまり、開発者としては、Twitter の大量の操作に自ら追われるよりも、ほとんどの作業をソフトウェアが自動的に行うようにさせたいと思うはずです。そこで、新しい Twitter アカウントを登録するだけでなく、Twitter 機能の特定の側面を自動化できるように API について学ぶことにしました。

あなたが真っ先に必要だと思ったのは、API を使って Joel Comm のタイムラインを取得することです (リスト 1 を参照)。今回の決心は彼の書いた本がきっかけとなっているので、これは当然のことです。

リスト 1. Joel Comm のタイムラインを取得する
http://twitter.com/statuses/user_timeline.xml?id=joelcomm

タイムラインを取得する方法は、このとおり単純そのものです。ブラウザーを開いて、上記の URL をアドレス・バーに貼り付けてアクセスし、何が表示されるかを見てください。

もちろん、ここではこの REST 呼び出しについて詳しく見ていきます。まず、http://twitter.com という接頭部は見てのとおり、twitter.com の部分がドメイン名です。つまり、このドメイン名に対応する IP アドレスを使ってリソースにアクセスすることができます。ドメイン名の前にある http は、Hypertext Transfer Protocol を使用することを意味します。これは、REST ではよくあるケースです。

ドメイン名に続くのは /statuses です。Twitter ではこのようにして、特定カテゴリー内の REST 関数を指定します。これはいわば、ファイルシステム内のディレクトリーのようなものです。この例で呼び出される REST 関数は、statuses というカテゴリーに含まれます。Twitter の世界では、ユーザーの「近況 (status)」は基本的に「つぶやき」と呼ばれます。つぶやきが、ユーザーが今何をしているかを説明するからです。

その後に続く user_timeline は、実際に呼び出される関数の名前です。この関数には、user_timeline という直観的な名前が付けられています。事実、ここではユーザーの「タイムライン」、すなわちユーザーが最近入力した一連のつぶやきを取得しようとしています。

関数名に続く .xml 拡張子を見逃さないでください。これは重要な点です。この拡張子が、タイムラインをどのフォーマットで取得するかを指定するからです。ここでは XML を使用していますが、その他に有効なフォーマットとしては JSON (Java™ Simple Object Notation)、Atom、RSS があります。

関数の後には、標準的な GET 表記によるパラメーターが、疑問符 (?) で区切られて続きます。上記の例には 1 つのパラメーター、id しかありません。id は、タイムラインを表示する対象ユーザーの Twitter 名を指定するパラメーターです。上記では、タイムラインを表示したい唯一の対象ユーザーとして joelcomm が指定されています。


出力の評価

上記の出力を確認した末、あなたは Atom フォーマットで結果を受け取ったほうがよいことに気付きました。幸い、その場合でもまったく問題ありません。リスト 1 のコードに若干の変更 (リスト 2) が必要になるだけです。

リスト 2. Joel Comm のタイムラインを Atom で取得する
http://twitter.com/statuses/user_timeline.atom?id=joelcomm

上記の REST 呼び出しの結果は、リスト 3 のようになります。リスト 2 のコードを URL に貼り付けてアクセスすると、ブラウザーは結果の出力をダウンロードするように求めてくるはずです。なぜなら、あなたが使用しているブラウザーは、.atom 拡張子で終わるファイルを表示するようには構成されていないからです。

当然のことながら、Joel のタイムラインは、この記事が公開される頃には (そしてあなたがこの記事を読む時点では)、この記事を執筆している時点でのタイムラインとは変わっているはずです。そのため、正確な結果はもちろん以下に記載する結果とは異なります。

リスト 3. Atom フォーマットでの Joel Comm のタイムライン (要約)
<?xml version="1.0" encoding="UTF-8"?>
<feed xml:lang="en-US" xmlns="http://www.w3.org/2005/Atom">
  <title>Twitter / joelcomm</title>
  <id>tag:twitter.com,2007:Status</id>
  <link type="text/html" rel="alternate" href="http://twitter.com/joelcomm"/>
  <updated>2009-03-22T10:21:31+00:00</updated>
  <subtitle>Twitter updates from Joel Comm / joelcomm.</subtitle>
    <entry>
      <title>joelcomm: thinking...</title>
      <content type="html">joelcomm: thinking...</content>
      <id>tag:twitter.com,2007:http://twitter.com/joelcomm/statuses/1369295498</id>
      <published>2009-03-22T05:15:01+00:00</published>
      <updated>2009-03-22T05:15:01+00:00</updated>
      <link type="text/html" rel="alternate" 
	 href="http://twitter.com/joelcomm/statuses/1369295498"/>
      <link type="image/jpeg" rel="image" 
		href="http://s3.amazonaws.com/joel1_normal.jpg"/>
      <author>
        <name>Joel Comm</name>
        <uri>http://www.JoelComm.com</uri>
      </author>
    </entry>
</feed>

XML を使い慣れていれば、リスト 3 の大部分はすんなりと理解できるはずです。Atom を使い慣れているとしたら、一層馴染み深い内容のはずです。さらに Atom と Twitter を使い慣れているのであれば、このセクションは飛ばしてもらっても構いません。

リスト 3 のコードの内容は以下のとおりです。

  • ルート要素は feed であることに注意してください。これは Atom 仕様に従った標準的なスタイルです。Twitter が使用する名前空間、http://www.w3.org/2005/Atom は、ルート要素の属性として指定されます。
  • title 要素は、タイムラインを表示する対象となっているユーザーを識別します。また、Twitter Web サイトからのものであることを簡潔に示します。
  • link 要素も重要です。この要素は、Joel Comm のタイムラインを昔ながらの方法で (つまり、ブラウザーで手動により) 表示するときに使用する URL を指定します。
  • entry スタンザは、つぶやきを表します。上記では簡単のため、1 件のつぶやきしか記載していませんが、実際の出力には 20 件のつぶやきが表示されます。
  • titlecontent の内容が同じであることに注目してください。つぶやきにはタイトルがありません。そのため、タイトルが実際のつぶやきそのものになるのは当然のことです。Atom は記事のような文書を対象に設計されていることを思い出してください。記事では通常、見出しがあり、その後に本文が続きますが、つぶやきはその限りでないため、この 2 つの要素には同じ内容が含まれます。
  • Atom フォーマットでは、つぶやきの内容は Twitter 名とコロン (:) の後に続きます。上記の場合、joelcomm: の後に実際のつぶやきが続いています。
  • この例での実際のつぶやきは、非常に意味ありげな「thinking...」という文です。これが、私がこの記事を書いている時点での Joel の最新のつぶやきです。ひねくれた人はこのつぶやきから、Joel は何も考えていないとか、Joel は最新のつぶやきのネタがなかったけれども、何かしら入力しなければならないと思ったのだろうなどと推測するかもしれませんが、このような詮索は他の人にお任せします。
  • id は Atom に必要な要素で、これが、この特定のつぶやきのグローバル一意識別子 (GUID) です。個々のつぶやきを参照できるように、すべてのつぶやきには Twitter 全体のなかで一意の ID があります。
  • publishedupdated の日時もまったく同じです。Joel はつぶやきを入力するけれども、そのつぶやきを更新することはないため、これは当然と言えます。
  • 最初の link 要素は、この 1 つのつぶやきへのリンクを提供します。http://twitter.com/joelcomm/statuses/1369295498 をブラウザーに貼り付けてアクセスすると、その時点で Joel が「thinking… (考え中...)」であったことがわかります。
  • 2 番目の link 要素は、単に Joel の画像へのリンクを提供しているに過ぎません。
  • author スタンザは、この Twitter ユーザーに関する情報を提供します。上記では、Joel のフルネームと彼の Web サイトの URL が提供されています。

Twitter REST API の例をここまで見てきて、あなたはタイムラインが素晴らしい情報であること、そして Atom 出力を構文解析するコードは簡単に作成できることがわかりました。もちろん Joel Comm だけでなく、他の有力なユーザーのタイムラインを構文解析することも可能です。解析した情報は、オンライン・マーケティング・キャンペーンの関連データとして収集することができます。そこには無限の可能性があります。唯一の制約となるのは、あなたの想像力だけです。


その他のパラメーター

user_timeline には id の他にもいくつかのパラメーターがあります。例えば、上記の例で使用した id の代わりに、screen_name を指定することもできます。また、ユーザーが持っている数字の Twitter ID を知っている場合には、その番号を user_id に指定することができます。

since_id パラメーターは、このパラメーターに指定した番号よりも大きい値の ID を持つつぶやきを指定するために使用することができます (リスト 4 を参照)。上記の例で、Joel の有名な「thinking… (考え中…)」というつぶやきの ID は 1369295498 だったので、以下の URL を指定することにより、これより後のつぶやきが返されます。

リスト 4. 「thinking… (考え中…)」よりも後の Joel Comm のタイムラインを取得する
http://twitter.com/statuses/user_timeline.xml?id=joelcomm&since_id=1369295498

max_id パラメーターは基本的に since_id の逆で、パラメーターの値で指定された ID よりも小さい ID が設定されたつぶやきを返します。

since パラメーターを使用すると、ID ではなく、実際の日付をタイムライン・フィルターに適用することができます。また、page では結果にページ番号を付けられます。デフォルトの user_timeline 呼び出しは最新の 20 件のつぶやきを返すので、これらのつぶやきに 1 から 20 までの番号を付けるとしたら、リスト 5 のコードによって 41 番から 60 番までのつぶやきが返されることになります。

リスト 5. Joel Comm の 20 件ごとのつぶやきの 3 番目を取得する
http://twitter.com/statuses/user_timeline.xml?id=joelcomm&page=3

その他の関数

ここまで user_timeline 関数について広範に検討してきました。しかし、Twitter API が提供している REST によってアクセスできる関数は、これだけではありません

public_timeline 関数 (リスト 6) では、自分のつぶやきを公開しているユーザーに関して、Twitter 全体のなかで最も新しいつぶやきを表示することができます。

リスト 6. 最新のつぶやき
http://twitter.com/statuses/public_timeline.xml

friends_timeline 関数 (リスト 7) は、自分がフォローしている友達のつぶやきを表示するときに使用します。この関数によって得られる結果は、Twitter にログインして直接 Twitter ホーム・ページに進むことで得られる内容と同じです。

リスト 7. フォローしている友達の最新のつぶやき
http://twitter.com/statuses/friends_timeline.xml

リスト 7 の URL をブラウザーにコピー・アンド・ペーストしてアクセスすると、Twitter ユーザーのユーザー名とパスワードの入力を求めるプロンプトが表示されます。Twitter でのユーザーのホーム・ページには、ユーザーのダイレクトメッセージへのリンクが含まれているため、このホーム・ページはセキュアな環境になっています。これはつまり、Twitter 側でのセキュリティー対策となっています (セキュリティーについては、この後詳しく説明します)。

REST API を使用して実際につぶやきを投稿するには、update 関数を使用します。つぶやきを投稿する場合には、(GET リクエストではなく) POST リクエストを使用して、この関数を呼び出さなければなりません。実際のつぶやきのテキストは、POST リクエストによって送信される status パラメーターに含まれます。

replies 関数は、20 件の最新の @replies を認証ユーザーに返します。基本的に、@replies とは特定のユーザーのみを対象に投稿されたつぶやきのことです。例えば、「@joelcomm are you done thinking yet?」というつぶやきを投稿すると、このメッセージは Joel Comm 宛に送信された一連のメッセージのうちの 1 つとして表示されます。Joel Comm は自分の Twitter ホーム・ページでメッセージへのリンクをクリックすることで、これらのメッセージを表示することができます。ただし @replies を使った投稿は、その投稿したユーザーをフォローしているすべてのユーザーにも表示されます。

この記事では、すべての REST API 関数を詳細に説明することはしません。これらの関数については、API ドキュメントにわかりやすく解説されています。API ドキュメントへのリンクは、「参考文献」を参照してください。


API の使用に関する制約

Twitter の REST API を使用したからといって、何でも思いのままのことができるというわけではありません。Twitter ではその API の使用に際し、帯域幅を大量に消費して機能セットの有益性を危険にさらすことのないように、特定の制約事項を設けています。

第一に、ユーザーに許可されるリクエスト数は 1 時間あたり最大 100 件となっています。この上限は (POST ではなく) GET リクエストにのみ適用されますが、それでも大まかな制約としては有効な規則です。この上限を超えて REST を呼び出すと、制限数を超過したことを知らせる文書が返されます。理由が何であれ、Twitter REST API を呼び出さなければならない回数が 1 時間に 100 回を超える場合には、Twitter からホワイトリストを申請することができます。

もう 1 つの制約事項として、page または count パラメーターのいずれかを使用して返すことのできるステータスは最大 3200 件です。

さらに、Twitter はその他にも制約事項を要請していますが、強制まではしていません。例えば、Twitter では count 属性ではなく page 属性を使用するように忠告しています。また、同じステータスを何度も繰り返しリクエストするのではなく、結果をローカル・キャッシュに入れるようにも要請しています。

認証

前述したように、特定の関数には認証が必要です。Twitter REST API を使用して、この API の関数を利用したければ、リクエストに自分のクレデンシャルを組み込む必要があります。そうでないと、応答としてステータス・コード 401 を受け取ることになります。

この記事を執筆している時点では、Twitter がサポートしているのは HTTP Basic 認証のみです。つまり、リクエスト・ヘッダーにはユーザー名とパスワードを暗号化フォーマットで含めなければなりません。これに従えば、ブラウザーから Twitter にログインしているかのように Twitter API 関数をフルに利用できるようになります。Basic 認証についての詳細は、「参考文献」を参照してください。

Twitter では現在、セキュア・リクエストに対して OAuth 認証を可能にする方法に取り組んでいるところです。この記事を執筆している時点では、この開発はまだ完了していません。


まとめ

Twitter は、Web 2.0 のジャンルで卓越したサービスです。Twitter ではマイクロブロギングという方法によって、共通の興味を分かち合うユーザーからなるオンライン・ネットワークをまるごと構築することができます。

Twitter REST API を使用すれば、手動で可能な Twitter 操作のほとんどすべてを自動化することができます。プログラムによって特定のユーザーのタイムラインにアクセスすることも、そのユーザーに直接または間接的に返信することもできます。また、ユーザーのつぶやきから自分が興味ある特定の情報を検索したり、ある特定の基準でつぶやきをフィルタリングして独自のブログに表示したりすることもできます。

Twitter の可能性に限りはありません。

参考文献

学ぶために

  • Build a RESTful Web service」(Andrew Glover 著、developerWorks、2008年7月): REST と Restlet フレームワークの紹介のなかで、Representational State Transfer についてわかりやすく説明しています。
  • RESTful Web サービスの基本」(Alex Rodriguez 著、developerWorks、2008年11月): この記事でも、REST とその基本原則について分かりやすく概説しています。
  • Basic 認証: Basic 認証については、まずウィキペディアのエントリーを読んでください。Basic 認証について学ぶには最適な場所です。
  • Twitter REST API Documentation: API 全体の概要を、サンプルと併せて包括的に説明しています。
  • IBM XML 認定: XML や関連技術の IBM 認定技術者になる方法について調べてください。
  • XML Technical library: 広範な技術に関する記事とヒント、チュートリアル、標準、そして IBM Redbooks については、developerWorks XML ゾーンを参照してください。
  • developerWorks の Technical events and webcasts: これらのセッションで最新情報を入手してください。
  • developerWorks podcasts: ソフトウェア開発者向けの興味深いインタービューとディスカッションを聞いてください。

製品や技術を入手するために

  • Twitter サイト: Twitter サービスについて調べるには、このサービスで友達、家族、同僚に接続して、自分が何をしているかについての短いメッセージを交換してみてください。
  • IBM 製品の評価版: DB2®、Lotus®、Rational®、Tivoli®、および WebSphere® のアプリケーション開発ツールとミドルウェア製品を体験するには、IBM SOA Sandbox のオンライン試用版をダウンロードするか、検討してみてください。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=XML, Web development
ArticleID=407061
ArticleTitle=Twitter REST API の使い方
publish-date=06092009