Atom Publishing Protocol の用途と将来

2006 年のネット開発に向けて覚えるべき技術 のコメントで、Atom PP が何に嬉しい技術なのかいまいち掴めていないため、自信のない書き込みをしたところ、kwmr さんから Yoshimatsu さんの面白いブログのエントリを紹介いただいた。

バックエンド側からの情報注入の口として Atom Publishing Protocol は重要になるだろう、という話。

個々の企業から情報を提供させて、それらをまとめて提供する「場」を作ることで生計を立てているネットサービスというのがある。Yoshimatsu さんが言及されている Amazon はもちろんそうだし、Kakaku.com , ぐるなび, Home's なんかもそう、 Vector とかも提供者に個人が多いが同様ではないか。

これらの情報集積型ネットサービスは、当初は運営者が手作業で情報を入力したり営業をかけていたものが、情報量の増加とそれによるユーザ数の増加に伴って力関係が逆転し、今では情報提供側がお願いして/料金を払ってでも載せてもらうという形になってきている。これらのサービスで検索されないということは、ネット経由で探しているユーザ達にとっては世に存在しないも同様だからである。

当然、これらのサービス運営者達が情報を提供させるためのフォーマットやインタフェースを整備しているのは間違いないだろう。PC ショップはともかく、町の不動産屋やレストランのオーナーに CSV だの XML だのを直接書かせられるはずもない。実際にどうやっているのか知らないが、整備されたデータ更新専用のウェブサイトなり独自の PC クライアントなりが提供されているはず。

では、そういった情報注入側のインタフェースに関して、Atom PP 対応が進むか、と聞かれると、サービス側にあまりメリットが無いのではないか。新しく作る際に、都合のよいライブラリが揃ってるから、という理由で Atom PP を採択することはあるだろうけど、もし既存の独自プロトコルを使っているなら、それを Atom PP に置き換える意味までは無いように思う。

サービス提供側にしてみれば、同じデータを競合のところに簡単に持っていかれては困るわけで、たとえば Kakaku.com に価格情報を登録するインタフェースが Atom PP としてオープンになっていたら、Kakaku.com の競合サイトは「Kakaku.com と ○○ と △△ に一括登録できるクライアントツール」みたいなのをより簡単に作って配れてしまうのでは。ま、もちろん、クローズトなプロトコルであっても同様のツールは作れるだろうので、それだけで参入障壁とはいえなくても。