Atom Publishing Protocolは出来損ないか？

作者 Dilip Krishnan , 翻訳者 金森 諭 投稿日 2009年4月30日

セクション

設計/アーキテクチャ,

エンタープライズ・アーキテクチャ

トピック

REST ,

SOA

タグ

Adoption ,

Browsers ,

AtomPub ,

JSON

原文(投稿日：2009/4/22)へのリンク

「Atom Publishing Protocolは出来損ないだ」(リンク)Joe Gregorio氏は「その日のブログ誇張ノルマ」を達成するためにこのように述べている。この記事の大半はAtomPub採用の展望が予想よりかなり低いことについて書かれている。氏は「日々開発が続けられている新しいプロトコルは数多くあります。それらはAtomPubを使うこともできたはずです。しかしそうはなっていません。」と書いている。

AtomPubが「真の唯一のプロトコル」になれないのは、ブラウザの革新のためだと氏は考える。

AtomとAtomPubが始まった2002年とは違う世の中になりました。ブラウザはずっとパワフルになり、ブラウザ間のJavascriptの互換性は向上を続け、まだある違いも多くのライブラリによってカバーされていますし、接続性も上昇傾向にあります。これらの変化を前にして、当初AtomPubが必要だとされた理由がどれだけ持ちこたえられるでしょうか。

氏によると、AtomPubによって達成されるはずだった主な事柄のうちのいくつかは、ブラウザ技術の発展によって簡単に実現できるようになったか、もはや大した問題ではなくなったのだという。

1. 当時ブラウザにできるのは「編集」に限られていて、AtomPubはファットクライアントやRIAによって使用されるものとして作られた。

現実には機能がどんどんブラウザに取り込まれ、それにより編集プロトコルは推進力の一部を失っているのです。

2. AtomPubはオフラインでの編集を想定して設計された。

別の目的は「飛行機の中で編集する」ことを実現することでした。常にオンラインでいることはできない、オフラインの時はブラウザを使うことができないとい う考えがありました。この月並みなアイディアのうちVirgin Atlantic航空（先駆けて機内インターネット接続を導入）にもEDGE（世界の多くの地域で使える携帯電話用の通信規格）でも出来ない事柄につい て、Google Gearsや分散型バージョン管理システムが解決策となります。

3. 共通の交換フォーマットとなる。

この場合の「問題」は、2002年以降により良いフォーマットが現れたことです。ブラウザとJavascriptの申し子であるJSONは「データ」の交 換フォーマットとしては完璧ですし、そこが「データ」交換と「文書」交換の違いなのだと考えています。もしＡの時点からＢの時点のデータを取得したいだけ なら、データ構造へ直接マッピングできるJSONの方がずっと生成するのも利用するのも簡単です。

氏はさまざまなサービスにおけるAtomPubの成功例をあげて、「ブラウザの機能とネットへの接続の向上によってAtomPubが広く使われるようになれなかった」と結論で述べている。

あるプラットフォームから別のプラットフォームへとデータを移行するといった他のケースでも持ちこたえています。おそらくAtomPubをベースにしたサービスを一番出しているのはGoogle Data API（リンク）をもつGoogleでしょうが、他のサービスでもサポートはされています。Flickrも画像をブログに表示できるようにするのにAtomPubを使っているのをつい最近知ったところです。

Dare Obasanjo氏も同じような感想を述べている(リンク)。

WebでAPIを公開するのにオブジェクト指向のJSONが文書指向よりも人気となることがAtom Publishing Protocolにとっての危機的状況を作り出してきました。

Microsoftがクラウドサービス（参考記事）を提供する（参考記事）にあたってAtomPubに賭けたこと、そしてGoogleもGoogle Data API（参考記事・英語）を中心にAtomPubに投資していることからすると、結局はそれほどの出来損ないではないのかもしれない（リンク）。Joe Gregorio氏の元記事はこちら（リンク）から。

• 次へ >