AOL WebAIM APIを注目すべき５つの理由 - snippets from shinichitomita’s journal

AOL OpenAuthがすごいとか、JSONPによる認証だとか騒いでたけど、もう去年の１１月にAOL Web AIM APIが公開されていたということについて、なんで気づいてなかったのか。一年近くもこれを正当に評価してこなかったことは、恥ずべきことだ。

Web AIM APIは、以下の理由で画期的、あるいはちょっとネガティブな側から見れば問題児なAPIである。そして、これからWebサービス APIを設計／開発する人、およびWebのセキュリティを考える人にとっては、少なくとも現在こういったWebサービスの実装が存在していることについては、ちゃんと注視しておかなければならない。

1. サーバレスでメッセンジャーアプリを構築できる

これがとりあず一番目に重要なポイント。これはAPIリクエストとしてJSONP形式のバインディング(運搬方法)を採用していることによる。サーバレスでアプリが作れることのメリットはあえては触れないが、少なくとも現在、数多くのWebサービスAPIがJSONPインターフェースを採用しているのはそのメリットを感じてるからこそだろう。ちなみにJSONP以外の通常のメッセージバインディングもあるので、PHPやらRubyやらでサーバアプリを書くことももちろんできるはず。ただ、他のAPIと比べて別段そこに面白みはないので、今回はそこには触れない。

2. AOL OpenAuth を使った実装である

AOL OpenAuthの仕様のエキセントリックさについては既に書いた。ただ、今となっては、それはほぼ先行して公開されたWeb AIMの仕様に起因していたと考えてよい、と思う。OpenAuthの特徴について端的に言うと、Pure JavaScriptのクライアントでサーバレスで分散認証（正確には個人情報のクレームになると思うけど）ができる、というものである。これももちろん他の分散認証APIと同様にサーバプログラムから使う方法もあるだろうけど、同様にそれほど面白みがないので、ここでは触れない。

3. JSONPでプライベートデータを配信している

AIM はインスタントメッセージングサービスであり、あるユーザが互いにメッセージを送る対象のID（スクリーンネーム）のリストを友達リストという形でサーバに保存している。この情報はもちろん一般に公開された情報ではなく、プライベートなものである。

誰でもアクセス可能なパブリックな情報と違って、プライベートな情報にアクセスするためには、まず情報へのアクセスを要求している主体が誰であるかを示さないといけない。そのために、2. であげた認証APIがあることが前提になる。

そして、何かしらの外部サービスがプライベート情報へのアクセス要求を「代理で行う」ような場合、その「代理人」がプライベートデータを扱ってよいかどうかをユーザに対して同意を求める、というプロセスを設けるのが一般的である。このあたりは、Google Calendar、Flickr などへの3rd Party WebアプリからのAPIアクセスにおいても、ユーザのプライベートリソースにアクセスするときには画面遷移の間に同意画面が用意されているので、もしかしたらお馴染みかもしれない。ただこれらと違うのは、GoogleもFlickrもサーバプログラムの利用が前提なのに対し、先にも説明した通り Web AIMにはJSONP バインディングがあり、Webアプリでありながらすべてサーバレスで動かせる。

4. JSONPを参照のみでない更新系リクエストにも利用している

プライベートリソースへのアクセスが出来るのなら、必然的に更新についても出来るようになる。更新といってもIMの送信だけど、状態変化をともなうようなJSONPってのは、少なくとも自分はこれとはてなスター以外に知らない。はてなスターは用途が限られるため勝手な書き込みリクエストが起こってもそれほど被害はないだろうけど、IMメッセージがWebアプリによって勝手に送信されたら結構困る。なので、3. で述べた同意のシステムが重要になってくる。

5. IMのイベントの配信にJSONP Cometをつかっている

AIMはIMだからサーバからイベントの通知が出来ないとAPIとしては完全ではありません。これは、Cometを使ってイベント待ちのURLにコネクションを張っておくことによって実現している。

JSONPでCometというのは、おそらく大半の人はLingrを思いつくだろうけど、LingrのCometがJSONPだったのはRuby on RailsサーバとJettyサーバとを分ける必要があったためだったらしい。その他にもしかしたら、同一ドメインへのブラウザコネクション制限の解決もあっただろうか。しかしWeb AIMのJSONP Cometについては、おそらく純粋にAPIという形で他のサイトからクロスドメインで使うためだろう。ちなみにイベント待ちのJSONPリクエストのURLは、その他のAPIで接続するホストとは異なるURLになるらしく、そのため同一ドメインの接続制限も回避される（たぶん）

Web AIMのJavaScriptによる実装例についてはこちら（dojo利用、iPhone を意識したUI）。ちなみに、WebAIMをラップした形で、アプリから簡単に使えるようにAIM Whimsicalsというのもある。

所感

AOL AIM を使うひとってそれほど多くないと思うので、実質このAPIのインパクトは薄いと思う。半年以上も日本で無視されて来た（ように思える）のは、それも理由の一つだろうし。だから、いまからWebサービスのAPIを作ろうという人で、この実装の重要さに共感してくれた人は、ぜひまねして（参考にして）ほしい。もちろん、彼らがちゃんと気にしているセキュリティのところまで理解してコピーしないと駄目だけど。きっと今更TwitterのAPIをまねるのなら、Web AIMをまねた方が絶対かっこいい。

セキュリティの面からこの実装に対して懐疑的な人は、ぜひなぜそれでは駄目なのかを検証して、そしてよければ教えてほしい。AOLがやってるからって絶対穴がないよということはないだろうし。そういう意味では上の段落で安易にコピーを勧めたのは軽率だったかもしれないけども。

所感２

JSONP CometのAPIは、通知のインフラとして使えるんじゃないか、と思う。例えばあるユーザがリンクをクリックしたら、他の友達ユーザにクリック情報が配信されて画面が更新されるとか。あとサーバレスなのを活かして自分のブログに埋め込んで、ブログ訪問者に対してIMで宣伝を流すとか（うざい）

所感３

「JSONPで秘密情報にアクセスさせるな」という教えは、たぶんセキュリティも何も考えてないひどい実装を避けるための教えだと解釈しているのですが、誰もがそこで思考停止していたら、この実装は出てこなかったのではないかなあ。