Webカレンダーの30Boxesが「出す」と宣言していたAPIの一端を公開した。まだイベントの作成と更新が公開されていないが、それが出れば手元のツールと同期するプログラムとか簡単に書けそうだ。
Google、Amazon、eBayで始まったWeb APIの大きな流れは、当初の読み取り専用データのWeb公開(Open Data!)を経て、Flickr APIとその仲間たちやAtom PPのような更新できるAPI(をSPIと呼んだこともあったっけ)へと歩を進めつつある。
更新できるAPIで重要なのは、認証機能だ。30Boxesも、カレンダーにデータを追加することを念頭においているわけだから当然だが、最初から認証機能が用意されている。こんなAPI呼び出しでユーザーの承認を受けることができる。Flickrとその仲間たちも同じような仕組みでユーザーがアプリへ承認を与えることができる。Amazon Web サービスも最近共有秘密による認証をシステムに組み込んだ。
ここで重要なのは、彼らはHTTPのBasic認証メカニズムを使っていないということだ。Basic認証などのHTTPのメカニズムでは、ユーザーはサードパーティのアプリケーションに、そのアプリケーション用ではなく、他のサービスにおける自分のパスワードを教えなければならないからだ。Flickr!は僕が2005年のDevelopers Summitでデモしたときは写真のアップロードにBasic認証を使っていたが、その後現在の仕組みを構築した。Web APIでユーザーのパスワードをアプリケーションに対して入力させるような認証機能は今すぐ仕組みを考え直したほうがいい。パスワードは常にユーザーとサービスとの直接対話でのみやり取りされなければならない。でないとman in the middle認定されてしまう。
と、ここまでの話は実はほとんど先日miyagawaさんとチャットしたときにmiyagawaさんがおっしゃったことだ。miyagawaさんはずっと以前にすでに書いてたし(追記)。日本でも多くのWeb APIが公開されているのは喜ばしいことだけど、どれも認証に本気で取り組んでない感じがする。Open Dataはもう当たり前。あちらのほうでは更新できるWeb APIも当たり前になりつつある。Flickr APIの認証はアプリ作成がちょっと面倒になる場合がある(僕のMTプラグインとか)が、とりあえずそれでもいいし、TypekeyでもOpenIDでも試してみる価値はあるだろう。はてなやmixiは、そのサービスでのアイデンティティがそのまま他のサービス上でも通用することもあるわけで、認証APIがあればサービスの価値が大いに高まると思う。