第1回　Web APIの次世代標準プロトコル

Web APIの乱立とAtom

現在、一般コンシューマ向けのWebサービスは多くのサイトがネットワーク越しに利用できるAPI（Application Programmable Interface）を公開しています。いわゆるWeb APIと呼ばれるものです。開発者向け技術雑誌などを見ても、マッシュアップやAPIプログラミングの解説記事が多く掲載されるようになりました。

2000年代の前半からGoogleやAmazonをはじめとした主要なWebサービスがAPIを公開し始めました。2000年代中盤からは様々なサイトでAPIが公開されるようになり、現在に至っています。当初はWebで人間がアクセスできる情報をAPIとして公開していましたが、現在ではWebブラウザで情報提供はしないもののAPIだけ提供するというサイトも増えてきました。

さて、これらのWeb APIアーキテクチャを見てみると、現状では各サービス毎にそれぞれ違うアーキテクチャを採用しています。使いたいWeb APIがあれば毎回アーキテクチャを確認してプログラミングしなければならない状況あると言えるでしょう。

少々乱暴ではありますが現状を以下のようなジャンルに分けてみました（分類は筆者による⁠）⁠。

1．REST志向 Web API: 決められたURLに対してHTTPのGETやPOSTを行い、XMLやXHTMLなどのデータを取得する形です。
2． RPC志向 Web API: HTTPのbody部分にメソッドやパラメタ情報を埋め込み、決められたURLに対してHTTPアクセスを行う方法です。レスポンスもXMLで表現されます。
3．Web Services志向 Web API: SOAPやWSDLといったWS系の仕様を使うタイプです。エンタープライズ系のWebサービスがAPIを提供する際に多く使われることがあるようです。

それぞれに利点・欠点がありますが、直感的に理解しやすいこと、仕様が相対的に単純であることなどから、多くのコンシューマ向けWeb APIの場合、1．が利用されることが多いように思います。

近年、RESTアーキテクチャはWebシステムのデザインアーキテクチャとして尊重されつつあります。詳しくは他の文書に譲りますが、REST的な考え方の一部となっているのは、GET, POST, PUT, DELETEなどのHTTPメソッドで直感的に操作するアーキテクチャです。

Atomもこの考え方を採用しており、初めてこのプロトコルを利用するエンジニアにとっても分かりやすいものとなっています。例えば、Webリソースに対してその情報を取得する場合は、GETメソッド、新規に作成する場合はPOST、変更する場合はPUT、削除する場合はDELETEメソッドを利用します。メソッドを適用するURLは対象となるリソースを想定しており、非常に直感的です。

現状、REST志向のWeb APIは多くのサイトが独自フォーマットかつ独自のアクセスモデルを採用しています。クライアントの開発者は一つ一つのサイトに対して、その通信フォーマットと通信プロトコルを確認しながら開発を進めていかなければなりません。このため、あまり相互運用性が考慮されていない状況であるように思えます。

AtomはこういったREST志向のWeb APIに対して標準的なフォーマットと標準的なアクセスモデルを提供してくれます。今後はAtomが相互運用性が考慮されたWeb APIの世界を切り開いてくれることを期待しています。

Atom アーキテクチャ

Atomは主に二つの仕様から構成されています。The Atom Syndication Format（RFC 4287）及びThe Atom Publishing Protocol（RFC 5023）です。Atom Syndication Formatは、RSSのようにシンジケーション（フィードを通じて配信すること）を行うためのフォーマットを定義しています。

本稿を執筆させていただいている2007年末現在、Webサイトのコンテンツ ─⁠─ とりわけブログやニュースサイト等の情報は、その多くがRSSやAtomなどの「フィード」として配信されています。フィードは、コンテンツそのものやサマリだけが記載されているのではなく、日付情報や、作者情報といったメタ情報と呼ばれる関連情報が一緒に配信されています。これらのメタ情報を活用してさまざまなアプリケーションが登場することが期待されています。まさに「フィード」は情報を流通させるためのデファクトスタンダードと言えるでしょう。しかし、これまでは情報の流れはサーバからクライアントへの一方向でした。クライアント側からサーバ側への情報の流れは未定義だったのです。

Atom Publishing Protocol （⁠以下、AtomPub）ではこのAtom Syndication Formatで定義されているフォーマットを利用し、Webリソースの操作方法を定義しています。言い換えるとクライアント側からサーバ側への情報の出版（publishing）を定義しているのです（図1⁠）⁠。

AtomPubの特徴

AtomPubはクライアント側からサーバ側への情報の出版を定義するものですが「できること」を一言でいうと、「⁠メタデータを伴ったWebリソースの取得・更新・追加・削除」となるでしょう。

ファイル転送プロトコルではない

Webリソースの更新・追加・削除は、従来からあるFTPやRCP, SCPといった既存のファイル転送プロトコルでもできるのではないかと思われる方もいらっしゃるかもしれません。確かにそうです。では一体何が違うのでしょうか？

大きく一つ違うのは、単なるファイル転送プロトコルではなく、メタ情報を付加したWebリソース（ファイルの場合もあれば文書や文字列の場合もある）を対象としていることです。ちなみにWebDAVも「プロパティ」という機能を利用してメタ情報を扱うことができます。

FTPでもファイルを作成・更新・削除することはできますが、その作者や著作権情報などのメタ情報は一緒に転送することができません。もし可能だとしても、ファイルシステムやファイルフォーマットに依存してしまいます。例えば、Microsoft Office文書は作者の情報をファイルに格納できますが、テキストファイルではそのような情報は格納できません。

HTTPの枠内で仕様を規定している

WebDAVは分散オーサリングのためにHTTPを拡張したプロトコル設計になっていますが、AtomPubはこれと違い、HTTPの枠内で仕様を規定するというアプローチをとりました。このため、HTTPを知っている方であれば、新しい知識をあまり必要とせず、AtomPubを理解することができるでしょう。またHTTPをしゃべることができる実装であれば、理論上はHTTPライブラリの修正することなく、AtomPubで定義された部分を追加実装することができることになります。細かな点ですが、新しい技術が普及するためには重要なポイントの一つであると思います。

リソースのデータモデル

AtomPubは、これまでに述べてきたようにファイル転送プロトコルではありません。ですので、多くのファイルシステムで採用されている階層構造（ディレクトリ構造）とは異なるモデルを採用しています。図2に示します。

一番中心となるのは「コレクション」と呼ばれる Webリソースの集合と、その中に入る「メンバリソース」です。メンバリソースはこれまで述べてきたWebリソースに対応するものです。コレクションは複数持つことができます。

コレクションとメンバリソースは、The Atom Syndication Formatで規定されたXMLで表現（representation）することができます。メンバリソースをXMLで表現したものをエントリ、コレクションをXMLで表現したものをフィードと呼んでいます。

表1　リソースとXML表現の対応

リソースの種別	XML表現
メンバリソース	エントリ
コレクション	フィード

コレクションは数学的な集合と同じですので包含されるメンバリソースの順序はありません。また、コレクションはメンバリソースの集合ですので、コレクションの中にコレクションを持つことはできません（同じくフィードもエントリの集合であり、フィードを子要素として持つことができません⁠）⁠。このためフィード同士が直接階層構造を持つことはできません。

コレクション及びリソースはそれぞれを指し示すURLを持っています。これらは、一意で（unique）なければなりません。

また、コレクションを束ねる概念として、「⁠ワークスペース」というものが定義されていますが、その意味や使い方は定義されていません。単にコレクションを束ねる概念とだけ定義されています。

AtomPubの概要は、次回以降に詳しく述べていくことにします。

新しいプロトコルと標準化

Atomは、IETF（Internet Engineering Task Force）で標準化のための議論がなされています。RFC2616とかRFC4287といった番号付きの仕様を聞いたことがあるでしょうか？　少々乱暴な言い方になりますが、これらRFCを決めている組織がIETFです。例えばHTTPやFTPなどもIETFによって標準化されたプロトコルです。

Atomはアプリケーションレイヤとはいえ通信プロトコルの一つですから、相互接続性が特に重要です。とりわけ、このプロトコルは企業間通信で使われるものではなく、広く一般的に使われることを想定したプロトコルです。

このため、強い影響力を持つ企業が勝手に決めるとか、強い影響力持つサイトが独自に仕様を決めて普及することは極めて稀です。少々時間がかかったとしても、オープンな議論とバランスの取れた意思決定を経て、一般に認知されていくという標準化プロセスが必要です。

Atomを策定する面々はIETFを標準化する場として選びました。標準化議論が行われたのはApplications Areaに分類されるWG （⁠Working Group）の一つであるatompub WGです。Chairの一人はXMLの仕様を書いた一人であるTim Brayが務めました。彼は現在、Sun MicrosystemsでDirector of Web Technologiesのポジションにもあり、業界に大きな影響力を持っています。

AtomPubは2007年10月、RFC 5023となりました。著者の一人であるJoe Gregorioが最初のアイデアを出してからおよそ5年だそうです。5年もの長きの間、様々な意見にもまれてきた結果、良いものに仕上がっていると思います。

IETFでは自社の製品に実装しつつある、もしくは実装した技術仕様を標準化することが多く、RFCとなった技術仕様が実際に市場で使われ、主流になるケースが数多く存在します。Atompubも例外ではなく、Sun Microsystems、IBM、Microsoft、Oracle、SixApart、Googleといった業界の主要企業の社員が実装を行いつつ標準化議論に関わっています（もちろん NTTコミュニケーションズも！⁠）⁠。これらの会社がAtomアーキテクチャを持った製品を必ずしもリリースするとは限りませんが、リリースする可能性があるというサインであることも確かです。

こういった観点からも、Atom（とりわけ Atompub）はインターネットの上位層プロトコルの中でもサラブレッド的なプロトコルです。筆者はHTTP, XMLに次ぐ基盤プロトコルとなると信じています。ですからこの場を借りて皆さんにAtompubをご紹介させていただければと考えています。これからの連載にお付き合いいただけますと幸いです。

最後に本連載をさせていただくにあたり、早期よりこのような将来性のあるプロトコルにプロジェクトの時間を割かせていただいた元上司である倉本英太郎氏に感謝申し上げます。