REST, Atom, and WebDAV

株式会社インターネットイニシアティブ山田泰資 <tai@iij.ad.jp>

何の話？

● Atom や WebDAV の使い方

● Atom フォーマットの話

● WebDAV のデータモデルの話

…ではありません！（話としては出ます）

だから何の話？

● なぜ Atom や WebDAV があるのか？

● なぜそれは（任意のアレ）じゃないのか？

● Atom と WebDAV とは？その関係は？

● それっておいしいの？（任意のソレ）に使える？● 結局、何をどう使ったらよいのよ？● この先は？

己を知り、敵を知らずんば、百戦危うからず

簡単な用語説明

RSS, Atom (AtomFormat)● ウェブサイトコンテンツを「記事」とその一覧という

形で流通させるためのフォーマット。これを定期取得することで、多数のサイトの更新部分だけ素早く確認できる。音楽等の配信にも応用されている。

WebDAV, Atom (AtomPP)● ウェブ上のコンテンツを作成・編集するための　　

規格。WebDAV で言えば、Photoshop でサイト上の画像を編集しつつ、OpenOffice で XML を　　　同様に編集するというダイレクト操作ができる。

まずは、歴史から

いい加減なインターネット（違）の歴史

1991 1995 2000 2005

WebDAV (1999)

Ruby (1995)Perl5 (1995)Java (1995)

WWW (1991)CORBA (1991)

COM (1993)OLE2 (1993)

CGI (1994)

*ML (197x)

XML (1997) REST (2000)

XML-RPC (1998)

HTTP/1.1 (1997)

SOAP (1999)

RSS (1999)

PIE (2003)ATOM (2005)

Blogger API (2001)

*DB (197x)RPC (197x)

レイヤ・分野無視の

何がどうつながってる？

WebDAV (1999)

CGI (1994)

*ML (197x)

XML (1997)

REST (2000)

XML-RPC (1998)

HTTP/1.1 (1997)

SOAP (1999)

ATOM (2005)

MetaWeblog API (2002)

*DB (197x)

RPC (197x)

CORBA/DCE (1991)

WWW (1991)

DCOM (1996)

RSS (1999)

つながり説明（例）

例１：*DB（データベース・情報モデリング分野）から

● 階層化ストレージモデル → WebDAV に● ハイパーリンクモデル → WWW に● タプルスペースモデル → REST に● Uniform Interface 操作モデル → REST に例２：CGIから

● Resource/Representation 分離 → REST に● 図にはないが XML-RPC の前躯体としての CGI-

based なアドホック RPC というのも

ウェブという場に何でも出てきたため、掛け合わせの機会が増えた！

ちょっとまとめ

コードの中のデータ？データの中のコード？

1990 1995 2000 2005 未来

コードの世界

データの世界

独立した世界 緊密な連携 ?

対象の分野がシフトしているというよりも、用法によって両者が可換に扱われる事が増えた？

RPCコンポーネント

データモデリング

マークアップ

ドキュメントモデリング

ハイパーテキスト

それでは、本題の方の歴史へ

WebDAV の歴史

● 1992 年、ウェブ登場

● 1993 年、Writable Web は即置いてきぼりに

● 1996 年、ウェブオーサリングシステム乱立状態（FrontPage 拡張とかありましたね）

● 1996 年、標準化活動開始

● 1996-1998 年、要求仕様の整理や策定途上の XML とのすり合わせ、POST-only 仕様等の中間仕様の試行錯誤を続ける

● 1999 年、RFC2518 が策定（ただし V 抜き）

Atom 前夜 – RSS の登場と混乱

● 1999年、RSS 0.9 (RDF）を Netscape 社が開発

● 1999年、0.91 (RDF破棄）をリリース

● 1999年、Netscape 社は RSS を放棄　DaveWiner@UserLand が引き継ぐ

● 2000年、rss-dev グループがRSS 1.0 (RDF) を 開発

● 2000年、1.0 に前後して UserLand版 0.91 と 0.92 がリリース

● 2002年、MetaWeblog API が 0.92 を取り込む

そして2003年・・・

２つの RSS の背景● RDF な人は「RDF で自由に拡張」「セマンティック

ウェブの第一歩をRSSで実現」という方向

● DW は「オーバーデザイン捨て」「安・早・旨最強」というかなりの現実主義者

● そして、（よい意味で）頑固＞DW （当初は XML　名前空間不要とか XML-RPC は ASCII で十分とか、テコでも動かない）

そして2003年・・・

RDFer: 拡張できず、柔軟性もないじゃないか。未来は RDF だ

DW: データは互換性が命。そして名前空間もRDFも一般開発者の重荷

※ 当時の議論内容や各技術への見方などを要約した　　もので、本人の発言に忠実なものではありません

RSS 2.0 (and 3.0)、そして Atom● 2003年、RSS 2.0 リリース。拡張性の要望を受け入れて、XML 名前空間は入った…半分だけ

半分とは？

● RSS 2.0 の要素は名前空間に所属しない

● しかし、名前空間宣言をすれば、他の要素を RSS 2.0 形式に含めることは許される

つまり、RSS 2.0 に他のXML文書を入れるのはいいが、RSS 2.0 を他のXML文書に入れる時に問題がある

※ 片方向なので、すべてのXML文書をRSS2.0として扱わなくてはならなくなる

RSS 2.0 (and 3.0)、そして Atom● XML 名前空間の対応方法、そして RDF 非対応で完全に道が分かれることに

– 2.0 策定過程で「複雑すぎる？それなら RSS 3.0 は RFC-822 と plain text だな」など一部では半ば諦め、半ば冗談が

– 余談：実は、Atom 代替かつ 2.0 後継の RSS 3.0 の計画もある（進行中。ただしマイナー）

かくして、Atom 策定への道がスタート。紆余曲折を経て IETF で 2005 年に策定

Atom 解説編

現在の Atom● RSS のようなフィードフォーマットだけではない

● Atom の構成技術

– Atom Syndication Format（策定完了）

● フィード形式。これが RSS と対応

– Atom Publishing Protocol（議論中）

● ウェブリソースの編集プロトコル。*blog* API と対応

– その他、細かい拡張規格多数（議論中）

1) Decide on the conceptual model、2) Decide on a syntax 、3) Build a syndication format 、4) Build an archiving format 、5) Build a weblog editing protocol

ロードマップ

Atom Format でできること

● 任意件数のテキスト（エントリ）を１つの「フィード（購読可能単位）」としてまとめ、作成者などの属性を付加した形で表現できる

● これを交換することで、記事一覧の取得や、 AtomPP (Publishing Protocol) を併用して記事の作成・編集ができる

● （外部｜バイナリ）データは <link rel=”...” .../> と　　間接参照する形で配信

（できること自体は）RSS と同じ

そうすると、なぜ Atom は RSS でないのか？

一体どこが違うのか？

入らず。「実装上問題あり」「Atom のデータモデルはRDFとほぼ等価で変換可能」という主張から

そういえば RDF はどうなった？

● 実は内容もあまり変わらない。若干整理しただけ

● RSS 2.0 (30 要素)、AtomFormat (21 要素)● 含むことができる内容をより詳細に規定● １クリック購読ができるようになった（標準化された）● エントリだけ流通させることも可能になった

http://www.intertwingly.net/wiki/pie/Rss20AndAtom10Compared (AtomWiki)

<?xml version="1.0" encoding="utf-8"?><rss version="2.0"> <channel>

<title>Example Feed</title> <description>Insert witty or insightful remark here</description> <link>http://example.org/</link> <lastBuildDate>Sat, 13 Dec 2003 18:30:02 GMT</lastBuildDate> <managingEditor>johndoe@example.com (John Doe)</managingEditor> <item> <title>Atom-Powered Robots Run Amok</title> <link>http://example.org/2003/12/13/atom03</link> <guid isPermaLink="false"> urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a </guid> <pubDate>Sat, 13 Dec 2003 18:30:02 GMT</pubDate> <description>Some text.</description> </item> </channel></rss>

RSS 2.0 (Atom Wiki からのサンプル）

<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom"> <title>Example Feed</title> 　<subtitle>Insert witty or insightful remark here</subtitle> 　<link href="http://example.org/"/>　 <updated>2003-12-13T18:30:02Z</updated> 　<author> 　　<name>John Doe</name> 　　 <email>johndoe@example.com</email> 　</author> 　<id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>

　 <entry> 　　 <title>Atom-Powered Robots Run Amok</title> 　　 <link href="http://example.org/2003/12/13/atom03"/> 　　 <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id> 　　<updated>2003-12-13T18:30:02Z</updated> 　　<summary>Some text.</summary> 　</entry></feed>

Atom 1.0 (Atom Wiki からのサンプル）

Atom でのコンテンツ規定

● RSS ではテキスト部分が plaintext なのか HTML なのか曖昧な部分があり、コンテンツを安全に転送できなかった

<content type="xhtml" xml:lang="en" xml:base="http://diveintomark.org/"> <div xmlns="http://www.w3.org/1999/xhtml"> <p><i>[Update: The Atom draft is finished.]</i></p> </div></content>

リソースタイプを明示できるので、この問題が解決

１クリック購読への対応

● RSS はデータ中に自URLがないので、フィードだけから「発行元の購読」ができなかった

<?xml version="1.0" encoding="utf-8"?> <feed xmlns="http://www.w3.org/2005/Atom"> <title type="text">dive into mark</title> <id>tag:example.org,2003:3</id> <link rel="self" type="application/atom+xml" href="http://example.org/feed.atom"/>

発行元を明示できるので、この問題が解決

エントリのみ流通への対応

● RSSでは複数フィードのエントリを合成すると各々の発行元情報を保持できなかった

<entry xmlns="http://www.w3.org/2005/Atom"><id>tag:blogger.com,1999:blog-6356614.post-112679118686717868</id><title type="html">AtomEnabled's Atom Feed</title><source> <generator ...>...</generator> </source></entry>

<source> 要素の中に発行元情報を含められる

RSS or Atom?● 過去（RSS）に縛られないという取り組みでも、　　

機能はほぼ同じなので結局 RSS 2.3 位● 一旦作られたデータはなかなか消えない。特に、優劣がはっきりしない時は。

● 今後は RSS, RDF/RSS, Atom と、統一ではなく全形式への対応が必要

非常に情報量的な互換性が高いので、「AtomicRSS」と RSS 2.0 のサブセットで書いて、必要なら Atom に変換しようという話もある。出すほうはそれでよいが。

事情はあっても、RSS の厳密化＋拡張が欲しかった…

AtomFormat まとめ

● AtomFormat は RSS 2.0 とほとんど同じ

● 細部では改良が入っている。特に、コンテンツの　流通にはより適しているのは確か

● しかし、現実界のデータはほぼ RSS で、一斉に　代わる理由も特にない

● 結局 RSS/RDF/Atom の全対応が必要

● なんだかなぁ

データの合意が最も重要なのに…

AtomPP & WebDAV

Atom の本命は AtomPP?● AtomFormat は見てきたように、ほとんど RSS● RSS になく、そして明らかに *blog* API と違うもの

– Atom Publishing Protocol– REST アーキテクチャに従っている

– 要するに、普通の HTTP でコンテンツを操作できる

「普通のHTTP」とは何か？コンテンツ操作とは何か？WebDAV とどう違うのか？

もしかして、RSS との比較と同じような話？

IETF WG の憲章比較

The editing protocol enables agents to interactwith resources

... define extensions ... that enable remotecollaborative authoring of Web resources.

AtomPub

WebDAV

→ 「編集プロトコルによりリソースの操作を可能にする」

→ 「拡張を定義し、リソースの共同編集を可能にする」

？。同じような、同じでないような？

HTTP/WebDAV/Atom の包含関係

DAVHTTP

AtomPP

WebDAV= HTTP + XML + HTTP 機能拡張

AtomPP= HTTP + XML + HTTP 用法定義

プロトコルではなく、その使い方で規格の一部を規定している

WebDAV のデータモデル

ルートコレクション

コレクション A

コレクション B

コレクション D

リソース C

XML

XML

XML

XML

XML

階層構造のリソース構成で、各リソースに各々任意の XML で記述できる属性（メタデータ）がくっついている

「階層」なので、URLは親コレクションの直下の必要がある

AtomPP のデータモデル

ワークスペース A

コレクション A

コレクション B

ワークスペース B

コレクション C

リソース A

Atom Entry A

リソース B

Atom Entry B

フィードの発行元＝コレクションで、コレクションはワークスペース単位でグループ化される。各コレクションはリソース一覧を持つ。コレクション種別により保持できるリソースが限定される。

階層ではないので、まったく別所のURLにあって構わない

属性は AtomFormat で規定の範囲に限定される

基本的な差異（その１）

● WebDAV は再帰的な削除やコピーといった、「ファイルシステム的オペレーション」の概念がある

● AtomPP は対象はあくまでフラットなフィードで、　再帰的操作という概念がない

純粋なウェブなのは AtomPP。WebDAV は規格策定時にここの概念設計で議論になった

汎用用途のユースケースでは階層制約が必要。しかし、サービス構成の自由度には不利となる。

AtomPP は構成・用途を縛り、階層制約を外した

リソースの作成：WebDAV

PUT /colA/resA HTTP/1.1Host: example.orgContent-Type: application/hogewikiContent-Length: xxx

* DAV でのリソース作成

DAV では HTTP PUT でリソースを作成します。

HTTP/1.1 201 Created

WebDAV は HTTP/1.1 の枠内で PUT をそのまま利用

リソースの作成：AtomPPPOST /colA HTTP/1.1Host: example.orgContent-Type: application/hogewikiContent-Length: xxx

* AtomPP でのリソース作成

AtomPP ではコレクションへの HTTP POST でリソースを作成します。

HTTP/1.1 201 CreatedLocation: http://example.org/colA/xxx

AtomPP では PUT も使える一方、コレクションにPOST することで「無名」でリソース作成を行える

基本的な差異（その２）

● WebDAV では、常にクライアントがリソースの URL を把握している前提がある

● AtomPP では、「無名」のままリソースを作ることができる

カテゴライズ・命名が不要な blog 的な仕様をサーバサイドで実現するための差異

WebDAV でやると、qmail 式の非衝突名を使うか、PUT のセマンティクスを崩すか（絶対ない）の２択

特殊コレクション：AtomPPPOST /colA HTTP/1.1Host: example.orgContent-Type: application/atom+xmlContent-Length: xxx

<entry xmlns="http://www.w3.org/2005/Atom"> <title>Atom-Submitted Entry</title> <updated>2003-12-13T18:30:02Z</updated> <summary>Some text.</summary></entry>

HTTP/1.1 201 CreatedLocation: http://example.org/colA/xxx

AtomFormat で対応コレクションに POST すると、内容を解析して実際のコンテンツの更新を行う

特殊コレクション：WebDAV● WebDAV では「特別な」データタイプはない

● リソースに対する GET/PUT は、データ型によらず完全な内容がそのまま返却・保持される

AtomPP のこの部分は、プロトコルレベルではなく、特定のコンテンツを意識したアプリケーション処理

これが AtomPP が HTTP/WebDAV の系譜の標準プロトコルと異なる本質的な部分

メタデータの扱い：WebDAVPROPPATCH /colA/resA HTTP/1.1Host: example.orgContent-Type: text/xml; charset=UTF-8<?xml version=”1.0”?><D:propertyupdate xmlns:D=...><D:set><D:prop> <ical xmlns:i="urn:ietf:params:xml:ns:xcal"> <i:vevent>......HTTP/1.1 207 Multi-Status...

任意の XML 文書をリソースに関連付けできる、一種の XML-DB 付きコンテンツリポジトリ

メタデータの扱い：AtomPP● 汎用のメタデータ管理機構という概念自体がない

● 唯一、Atom entry 登録時に、AtomFormat 規定に従って、XML 名前空間を使い投入は許可される

● しかし、サーバー側の挙動は実装依存

WebDAV & AtomPP：その他

● その他の点については、ほぼ同様

● コレクション一覧取得、AtomFormat 以外の読み出し・書き込み・削除、全部本質的には同じ

● ただし、メソッド名や交換 XML 形式は異なる

WebDAV を拡張するという方向ではいけなかったのか？

AtomPP の選択● WebDAV は最小セットでも属性管理機能が　　　必要なこと、また、HTTP 程周知されていない

● Pure HTTP でなくては F/W 透過性などに劣り、　また、低機能デバイスでの対応の容易度もある

では、WebDAV サブセット + 拡張では？

AtomPP は HTTP の枠内で拡張する

しかしオチがあった

WebDAV は HTTP を改良して拡張する

AtomPP の見落とし

DAVHTTP

AtomPPDAVHTTP

AtomPPMinimalHTTP

HTTP の枠内で拡張する、はずだったが…

想定 実際

世の中の HTTP クライアントには GET/POST のみの実装があった！ – J2ME/Flash client

AtomPP in SOAP● 重要すぎて「クライアントが悪い」と言ってられない

● しかし GET/POST のみ設計にもできない

● やむなく SOAP (with POST) 経由で HTTP 相当の各種命令を通す API セットを定義することに

● 途中まで AtomPP の一部だったが、切り離されて拡張アクセス手段の１つとして策定中

現状を考慮して WebDAV の「HTTPを拡張する」手法を避けたものの、保守的になりきれず、微妙な部分を残してしまった

まとめ

● AtomPP と WebDAV は目的レベルではほぼ同一

● 設計上は、WebDAV が汎用性を主眼に置くのに対し、AtomPP は現在の blog のデータモデルに適応することを重視している

● モデル的には、共通のストレージモデルの上で AtomPP/WebDAV 両対応の実装は容易

● AtomPP は HTTP の枠内で保守的な拡張を目指したが、世のクライアントはさらにミクロな実装だった。

まとめ（意見です）

● Atom は方向は悪くないと思うものの、中途半端

● RSS を改善しているが、YetAnotherFormat で　分岐したことで、いかに交換方法が REST だとしても、肝心の部分で情報空間を分割してしまった。その価値はあったのだろうか？

● AtomPP は AtomFormat と直接関係ない（させる必要がない）。また、Photoshop/Office/OOo/...などの特定データ専門のカスタムアプリとの連携の道を閉ざしてしまった。　　　　　　　　　　　　　　　　　その価値はあったのだろうか？

● RESTが重要なのはデータのためで、逆ではない

REST について

ここまでの意味って何？

● ここまで、WebDAV/Atom について、登場背景や技術的・思想的な差について見てきたけれど・・・

● でも、それが一体何？

● 例えば BloggerAPI でやってて何が悪い？　　　　誰か困るの？

● 逆に言うと、Web/WebDAV/Atom が REST 云々といっても、それが実際の価値を生まなければ無でしかない。

– WebService, SemanticWeb, SOA...についても同じ

Back to NULL state● SOA も SOAP も WebService も SemWeb も

REST も Web も XML も何もいらない

● そもそも、何のために、何をしたいのだっけ？

NULL state

本当にやりたいこと

要件１：AさんとBさん、もしくはそれをサポートする機械が、情報を　　　　 交換・共有することで、何らかの処理を行いたい

要件２：事前の合意コストを最小化し、可能な限りの不特定多数の間で　　　　 上記処理を行いたい

情報量、そして処理の利益を最大化したい

情報を交換したい

要件１：どうするの？

情報交換・共有の大前提● 対象に関する共通の合意

● 情報の visibility+reachability （E2E principle 的）

● メタデータ・インタフェースだけの検索は、偽者だ！– データをくれ、データを

– Google がフルデータではなく <meta> だけ検索だったら？

要件２：どうするの？

合意コストの最小化● コード界では、連携は次の２箇所で行う

– インタフェース

– データ（パラメータ＋返り値）

● データの自動的共通理解は Hard SemWeb 問題

● では、インタフェースは消せないか？● そういえば、一般社会では人・組織は全員個別の○×インタフェース（おにぎり販売I/Fとか）を実装してるのか？I/Fの抽象度を上げて販売I/Fなのか？

ようやく REST というか Web

URI こそがプロトコル独立を保証する

– プロトコルを隠蔽する IDL が保証するのではない

– どの空間でも指し示せるメタプロトコル空間

– 情報レベルの E2E の基盤インタフェース隠蔽

– Uniform Interface は、要するにどこでもあるから 　　　どこにも（見え）ないのと等価ということ

– ただインタフェース抽象化のレイヤをあげても　　 Object class で終わるのがオチ

– これはプロトコル設計の方の概念 ＞ Uniform Interface

それでメリットは？

● 「万能」クライアントが存在できる

– Readonly は当然ウェブブラウザが存在する

– ReadWrite (CRUD) もできるようになる

– データ種別×アクセス手段の数のクライアントは悪夢

● 今あるデータは、参照可能性が維持されることが高い確度で保証できる（これ以下はないから）

● データの自己記述性が高ければ、世界中で勝手に大規模な decentralized system を構築できる

● 情報をどうするかという、本来の上位設計レイヤで考え、実装することができる

と、持ち上げたところで落とす

● CRUD できるといっても、一番重要なのは read で これが99%。だから、GET optimized されてれば残りをセマンティクスを無視してPOSTしてもあまり実益上は困らない

– POST はセマンティクス上、最強のトンネリング

● そして、RESTは実装上どうしても苦しい所がある

– その強力さとコストのトレードオフ

When not to use REST● LPC するとき REST する人はいない

● 一方、発注書（OOo形式）をワークフローシステム中で書いてオーダー発行するとき、LPC や OOo API 使う人はいない。

極めて抽象的なのは分かっているが、「状況次第」

When not to use REST?

REST-scale I/F は（あたりまえだが）細粒度でない

● すべてがバルクアップデート● 名前フィールド変えるだけでも全部更新● 性能が…でもこれは実は問題ではない（＄＄＄）● 裏のシステムが複雑になると、変更検知が激面倒

● A(B(C())) 的に複数のアクセスが連鎖するとき、稼動に必要なデータが必要以上に増える（データも細粒度でないから）

設計・実装レイヤで REST のトレードオフコストを抑えなくては

When not to use REST?

データのネーミングが足を引っ張る● データに名前が付かなくてはならない● バルクデータ１つならまだいい● 複数データの連携構造に分割すると…

– すべてのデータに absolute URI がいる（そうしないとデータ流通に問題がおきる）

– LPC/RPC なら id = 1 が、id = http://jugemujugemu/● 内部を細粒度 I/F にしても、REST-style -> LPC

-> REST-style のコールシーケンスで破綻

まとめ

● REST は強力。それは間違いない

● でも、REST-scale な美しいデータモデルの裏は、かなり実装が面倒

● これは設計・実装レベルの習熟度の問題なのか、それとも REST-scale と local-scale の混合に付随的なものか？

まだ、自分はよくわかってない。しかし、Webスケールでやりたければ…

その先

● REST はスケーラビリティのためにある

● だから、REST ありきではない

● データ利用をどこまで勝手にスケールさせるか、

● REST-friendly な連携モデルとデータこそが重要

１）データ（形式）の合意を作って、２）それを XHTML に埋めるなり、３）独立 XML にするなり、４）マシン処理可能な形式ならなんでも、５）とにかくウェブに乗っけてくっつけよう

ご清聴ありがとうございました