Fairly old (~2004) presentation on how distributed computing are becoming more and more resource-oriented, and why would you care about it (and its pitfalls).

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

2. 何の話？
● Atom や WebDAV の使い方
● Atom フォーマットの話
● WebDAV のデータモデルの話
…ではありません！（話としては出ます）

3. だから何の話？
己を知り、敵を知らずんば、百戦危うからず
● なぜ Atom や WebDAV があるのか？
● なぜそれは（任意のアレ）じゃないのか？
● Atom と WebDAV とは？その関係は？
● それっておいしいの？（任意のソレ）に使える？
● 結局、何をどう使ったらよいのよ？
● この先は？

4. 簡単な用語説明
RSS, Atom (AtomFormat)
●ウェブサイトコンテンツを「記事」とその一覧という
形で流通させるためのフォーマット。これを定期取
得することで、多数のサイトの更新部分だけ素早く
確認できる。音楽等の配信にも応用されている。
WebDAV, Atom (AtomPP)
● ウェブ上のコンテンツを作成・編集するための
規格。WebDAV で言えば、Photoshop でサイト上
の画像を編集しつつ、OpenOffice で XML を
同様に編集するというダイレクト操作ができる。

5. まずは、歴史から

6. レイヤ・分野無視の
いい加減なインターネット（違）の歴史
1991 1995 2000 2005
WWW (1991) Ruby (1995) SOAP (1999)
CORBA (1991) Perl5 (1995)
Java (1995) RSS (1999)
COM (1993)
OLE2 (1993) REST (2000)
XML (1997)
CGI (1994) Blogger API (2001)
HTTP/1.1 (1997)
PIE (2003)
RPC (197x) XML-RPC (1998)
ATOM (2005)
*DB (197x)
WebDAV (1999)
*ML (197x)

7. 何がどうつながってる？
*DB (197x)
HTTP/1.1 (1997) WebDAV (1999)
*ML (197x)
REST (2000)
ATOM (2005)
WWW (1991) RSS (1999)
SOAP (1999)
CGI (1994)
XML (1997)
XML-RPC (1998)
RPC (197x) DCOM (1996)
MetaWeblog API (2002)
CORBA/DCE (1991)

8. つながり説明（例）
例１：*DB（データベース・情報モデリング分野）から
● 階層化ストレージモデル → WebDAV に
● ハイパーリンクモデル → WWW に
● タプルスペースモデル → REST に
● Uniform Interface 操作モデル → REST に
例２：CGIから
● Resource/Representation 分離 → REST に
● 図にはないが XML-RPC の前躯体としての CGI-
based なアドホック RPC というのも

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

10. コードの中のデータ？
データの中のコード？
マークアップ
データの世界
ハイパーテキスト
ドキュメントモデリング
独立した世界 緊密な連携 ?
1990 1995 2000 2005 未来
データモデリング
RPC
コンポーネント
対象の分野がシフトしているというよりも、
コードの世界 用法によって両者が可換に扱われる事が増えた？

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

12. WebDAV の歴史
● 1992 年、ウェブ登場
● 1993 年、Writable Web は即置いてきぼりに
● 1996 年、ウェブオーサリングシステム乱立状態
（FrontPage 拡張とかありましたね）
● 1996 年、標準化活動開始
● 1996-1998 年、要求仕様の整理や策定途上の
XML とのすり合わせ、POST-only 仕様等の中間
仕様の試行錯誤を続ける
● 1999 年、RFC2518 が策定（ただし V 抜き）

13. 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年・・・

14. ２つの RSS の背景
● RDF な人は「RDF で自由に拡張」「セマンティック
ウェブの第一歩をRSSで実現」という方向
● DW は「オーバーデザイン捨て」「安・早・旨最強」と
いうかなりの現実主義者
● そして、（よい意味で）頑固＞DW （当初は XML
名前空間不要とか XML-RPC は ASCII で十分と
か、テコでも動かない）
RDFer: 拡張できず、柔軟性もないじゃないか。未来は RDF だ
DW: データは互換性が命。そして名前空間もRDFも一般開発者の重荷
※ 当時の議論内容や各技術への見方などを要約した
もので、本人の発言に忠実なものではありません そして2003年・・・

15. 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として扱わなくてはならなくなる

16. 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 年に策定

17. Atom 解説編

18. 現在の 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

19. Atom Format でできること
● 任意件数のテキスト（エントリ）を１つの「フィード（購
読可能単位）」としてまとめ、作成者などの属性を
付加した形で表現できる
● これを交換することで、記事一覧の取得や、
AtomPP (Publishing Protocol) を併用して記事の
作成・編集ができる
● （外部｜バイナリ）データは <link rel=”...” .../> と
間接参照する形で配信
（できること自体は）RSS と同じ

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

21. 一体どこが違うのか？
● 実は内容もあまり変わらない。若干整理しただけ
● RSS 2.0 (30 要素)、AtomFormat (21 要素)
● 含むことができる内容をより詳細に規定
● １クリック購読ができるようになった（標準化された）
● エントリだけ流通させることも可能になった
http://www.intertwingly.net/wiki/pie/Rss20An
dAtom10Compared (AtomWiki)
そういえば RDF はどうなった？
入らず。「実装上問題あり」「Atom のデータモデルは
RDFとほぼ等価で変換可能」という主張から

22. RSS 2.0 (Atom Wiki からのサンプル）
<?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>

23. Atom 1.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>

24. 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>
リソースタイプを明示できるので、この問題が解決

25. １クリック購読への対応
● 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"/>
発行元を明示できるので、この問題が解決

26. エントリのみ流通への対応
● 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> 要素の中に発行元情報を含められる

27. RSS or Atom?
● 過去（RSS）に縛られないという取り組みでも、
機能はほぼ同じなので結局 RSS 2.3 位
● 一旦作られたデータはなかなか消えない。特に、
優劣がはっきりしない時は。
● 今後は RSS, RDF/RSS, Atom と、統一ではなく
全形式への対応が必要
非常に情報量的な互換性が高いので、「AtomicRSS」と
RSS 2.0 のサブセットで書いて、必要なら Atom に
変換しようという話もある。出すほうはそれでよいが。
事情はあっても、RSS の厳密化＋拡張が欲しかった…

28. AtomFormat まとめ
● AtomFormat は RSS 2.0 とほとんど同じ
● 細部では改良が入っている。特に、コンテンツの
流通にはより適しているのは確か
● しかし、現実界のデータはほぼ RSS で、一斉に
代わる理由も特にない
● 結局 RSS/RDF/Atom の全対応が必要
● なんだかなぁ
データの合意が最も重要なのに…

29. AtomPP & WebDAV

30. Atom の本命は AtomPP?
● AtomFormat は見てきたように、ほとんど RSS
● RSS になく、そして明らかに *blog* API と違うもの
– Atom Publishing Protocol
– REST アーキテクチャに従っている
– 要するに、普通の HTTP でコンテンツを操作できる
「普通のHTTP」とは何か？コンテンツ操作とは何か？
WebDAV とどう違うのか？
もしかして、RSS との比較と同じような話？

31. IETF WG の憲章比較
AtomPub
The editing protocol enables agents to interact
with resources
→ 「編集プロトコルによりリソースの操作を可能にする」
WebDAV
... define extensions ... that enable remote
collaborative authoring of Web resources.
→ 「拡張を定義し、リソースの共同編集を可能にする」
？。同じような、同じでないような？

32. HTTP/WebDAV/Atom の包含関係
プロトコルではなく、その使い方で
規格の一部を規定している
HTTP
DAV
AtomPP
WebDAV
= HTTP + XML + HTTP 機能拡張
AtomPP
= HTTP + XML + HTTP 用法定義

33. WebDAV のデータモデル
XML
ルートコレクション XML
コレクション A XML
コレクション B
XML
リソース C
「階層」なので、URLは
XML 親コレクションの直下の
必要がある
コレクション D
階層構造のリソース構成で、各リソースに各々任意の XML で
記述できる属性（メタデータ）がくっついている

34. AtomPP のデータモデル
ワークスペース A ワークスペース B
コレクション A コレクション C
リソース A 階層ではないので、まったく
別所のURLにあって構わない
リソース B
コレクション B
Atom Entry A 属性は AtomFormat で
規定の範囲に限定される
Atom Entry B
フィードの発行元＝コレクションで、コレクションはワークスペース
単位でグループ化される。各コレクションはリソース一覧を持つ。
コレクション種別により保持できるリソースが限定される。

35. 基本的な差異（その１）
● WebDAV は再帰的な削除やコピーといった、「ファ
イルシステム的オペレーション」の概念がある
● AtomPP は対象はあくまでフラットなフィードで、
再帰的操作という概念がない
純粋なウェブなのは AtomPP。WebDAV は規格
策定時にここの概念設計で議論になった
汎用用途のユースケースでは階層制約が必要。
しかし、サービス構成の自由度には不利となる。
AtomPP は構成・用途を縛り、階層制約を外した

36. リソースの作成：WebDAV
PUT /colA/resA HTTP/1.1
Host: example.org
Content-Type: application/hogewiki
Content-Length: xxx
* DAV でのリソース作成
DAV では HTTP PUT でリソースを作成します。
HTTP/1.1 201 Created
WebDAV は HTTP/1.1 の枠内で PUT をそのまま利用

37. リソースの作成：AtomPP
POST /colA HTTP/1.1
Host: example.org
Content-Type: application/hogewiki
Content-Length: xxx
* AtomPP でのリソース作成
AtomPP ではコレクションへの HTTP POST でリソース
を作成します。
HTTP/1.1 201 Created
Location: http://example.org/colA/xxx
AtomPP では PUT も使える一方、コレクションに
POST することで「無名」でリソース作成を行える

38. 基本的な差異（その２）
● WebDAV では、常にクライアントがリソースの
URL を把握している前提がある
● AtomPP では、「無名」のままリソースを作ることが
できる
カテゴライズ・命名が不要な blog 的な仕様を
サーバサイドで実現するための差異
WebDAV でやると、qmail 式の非衝突名を使うか、
PUT のセマンティクスを崩すか（絶対ない）の２択

39. 特殊コレクション：AtomPP
POST /colA HTTP/1.1
Host: example.org
Content-Type: application/atom+xml
Content-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 Created
Location: http://example.org/colA/xxx
AtomFormat で対応コレクションに POST すると、
内容を解析して実際のコンテンツの更新を行う

40. 特殊コレクション：WebDAV
● WebDAV では「特別な」データタイプはない
● リソースに対する GET/PUT は、データ型によらず
完全な内容がそのまま返却・保持される
AtomPP のこの部分は、プロトコルレベルではなく、
特定のコンテンツを意識したアプリケーション処理
これが AtomPP が HTTP/WebDAV の系譜の
標準プロトコルと異なる本質的な部分

41. メタデータの扱い：WebDAV
PROPPATCH /colA/resA HTTP/1.1
Host: example.org
Content-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 付きコンテンツリポジトリ

42. メタデータの扱い：AtomPP
● 汎用のメタデータ管理機構という概念自体がない
● 唯一、Atom entry 登録時に、AtomFormat 規定に
従って、XML 名前空間を使い投入は許可される
● しかし、サーバー側の挙動は実装依存

43. WebDAV & AtomPP：その他
● その他の点については、ほぼ同様
● コレクション一覧取得、AtomFormat 以外の読み
出し・書き込み・削除、全部本質的には同じ
● ただし、メソッド名や交換 XML 形式は異なる
WebDAV を拡張するという方向ではいけなかったのか？

44. AtomPP の選択
● WebDAV は最小セットでも属性管理機能が
必要なこと、また、HTTP 程周知されていない
では、WebDAV サブセット + 拡張では？
● Pure HTTP でなくては F/W 透過性などに劣り、
また、低機能デバイスでの対応の容易度もある
AtomPP は HTTP の枠内で拡張する
WebDAV は HTTP を改良して拡張する
しかしオチがあった

45. AtomPP の見落とし
HTTP の枠内で拡張する、はずだったが…
HTTP HTTP
DAV DAV
AtomPP AtomPP
Minimal
HTTP
想定 実際
世の中の HTTP クライアントには GET/POST のみの
実装があった！ – J2ME/Flash client

46. AtomPP in SOAP
● 重要すぎて「クライアントが悪い」と言ってられない
● しかし GET/POST のみ設計にもできない
● やむなく SOAP (with POST) 経由で HTTP 相当
の各種命令を通す API セットを定義することに
● 途中まで AtomPP の一部だったが、切り離されて
拡張アクセス手段の１つとして策定中
現状を考慮して WebDAV の「HTTPを拡張する」手法を避けた
ものの、保守的になりきれず、微妙な部分を残してしまった

47. まとめ
● AtomPP と WebDAV は目的レベルではほぼ同一
● 設計上は、WebDAV が汎用性を主眼に置くのに
対し、AtomPP は現在の blog のデータモデルに
適応することを重視している
● モデル的には、共通のストレージモデルの上で
AtomPP/WebDAV 両対応の実装は容易
● AtomPP は HTTP の枠内で保守的な拡張を目指
したが、世のクライアントはさらにミクロな実装だっ
た。

48. まとめ（意見です）
● Atom は方向は悪くないと思うものの、中途半端
● RSS を改善しているが、YetAnotherFormat で
分岐したことで、いかに交換方法が REST だとし
ても、肝心の部分で情報空間を分割してしまった。
その価値はあったのだろうか？
● AtomPP は AtomFormat と直接関係ない（させる
必要がない）。また、Photoshop/Office/OOo/...な
どの特定データ専門のカスタムアプリとの連携の
道を閉ざしてしまった。
その価値はあったのだろうか？
● RESTが重要なのはデータのためで、逆ではない

49. REST について

50. ここまでの意味って何？
● ここまで、WebDAV/Atom について、登場背景や
技術的・思想的な差について見てきたけれど・・・
● でも、それが一体何？
● 例えば BloggerAPI でやってて何が悪い？
誰か困るの？
● 逆に言うと、Web/WebDAV/Atom が REST 云々
といっても、それが実際の価値を生まなければ無
でしかない。
– WebService, SemanticWeb, SOA...についても同じ

51. Back to NULL state
● SOA も SOAP も WebService も SemWeb も
REST も Web も XML も何もいらない
● そもそも、何のために、何をしたいのだっけ？
NULL state

52. 本当にやりたいこと
情報量、そして処理の
利益を最大化したい
情報を交換したい
要件１：AさんとBさん、もしくはそれをサポートする機械が、情報を
交換・共有することで、何らかの処理を行いたい
要件２：事前の合意コストを最小化し、可能な限りの不特定多数の間で
上記処理を行いたい

53. 要件１：どうするの？
情報交換・共有の大前提
● 対象に関する共通の合意
● 情報の visibility+reachability （E2E principle 的）
● メタデータ・インタフェースだけの検索は、偽者だ！
– データをくれ、データを
– Google がフルデータではなく <meta> だけ検索だった
ら？

54. 要件２：どうするの？
合意コストの最小化
● コード界では、連携は次の２箇所で行う
– インタフェース
– データ（パラメータ＋返り値）
● データの自動的共通理解は Hard SemWeb 問題
● では、インタフェースは消せないか？
● そういえば、一般社会では人・組織は全員個別の
○×インタフェース（おにぎり販売I/Fとか）を実装し
てるのか？I/Fの抽象度を上げて販売I/Fなのか？

55. ようやく REST というか Web
URI こそがプロトコル独立を保証する
– プロトコルを隠蔽する IDL が保証するのではない
– どの空間でも指し示せるメタプロトコル空間
– 情報レベルの E2E の基盤
インタフェース隠蔽
– Uniform Interface は、要するにどこでもあるから
どこにも（見え）ないのと等価ということ
– ただインタフェース抽象化のレイヤをあげても
Object class で終わるのがオチ
– これはプロトコル設計の方の概念 ＞ Uniform Interface

56. それでメリットは？
● 「万能」クライアントが存在できる
– Readonly は当然ウェブブラウザが存在する
– ReadWrite (CRUD) もできるようになる
– データ種別×アクセス手段の数のクライアントは悪夢
● 今あるデータは、参照可能性が維持されることが
高い確度で保証できる（これ以下はないから）
● データの自己記述性が高ければ、世界中で勝手に
大規模な decentralized system を構築できる
● 情報をどうするかという、本来の上位設計レイヤで
考え、実装することができる

57. と、持ち上げたところで落とす
● CRUD できるといっても、一番重要なのは read で
これが99%。だから、GET optimized されてれば
残りをセマンティクスを無視してPOSTしてもあまり
実益上は困らない
– POST はセマンティクス上、最強のトンネリング
● そして、RESTは実装上どうしても苦しい所がある
– その強力さとコストのトレードオフ

58. When not to use REST
● LPC するとき REST する人はいない
● 一方、発注書（OOo形式）をワークフローシステム
中で書いてオーダー発行するとき、LPC や OOo
API 使う人はいない。
極めて抽象的なのは分かっているが、「状況次第」

59. When not to use REST?
REST-scale I/F は（あたりまえだが）細粒度でない
● すべてがバルクアップデート
● 名前フィールド変えるだけでも全部更新
● 性能が…でもこれは実は問題ではない（＄＄＄）
● 裏のシステムが複雑になると、変更検知が激面倒
● A(B(C())) 的に複数のアクセスが連鎖するとき、稼
動に必要なデータが必要以上に増える（データも細
粒度でないから）
設計・実装レイヤで REST のトレードオフコストを抑えなくては

60. When not to use REST?
データのネーミングが足を引っ張る
● データに名前が付かなくてはならない
● バルクデータ１つならまだいい
● 複数データの連携構造に分割すると…
– すべてのデータに absolute URI がいる（そうしないと
データ流通に問題がおきる）
– LPC/RPC なら id = 1 が、id = http://jugemujugemu/
● 内部を細粒度 I/F にしても、REST-style -> LPC
-> REST-style のコールシーケンスで破綻

61. まとめ
● REST は強力。それは間違いない
● でも、REST-scale な美しいデータモデルの裏は、
かなり実装が面倒
● これは設計・実装レベルの習熟度の問題なのか、
それとも REST-scale と local-scale の混合に付
随的なものか？
まだ、自分はよくわかってない。
しかし、Webスケールでやりたければ…

62. その先
● REST はスケーラビリティのためにある
● だから、REST ありきではない
● データ利用をどこまで勝手にスケールさせるか、
● REST-friendly な連携モデルとデータこそが重要
１）データ（形式）の合意を作って、２）それを XHTML に埋めるなり、
３）独立 XML にするなり、４）マシン処理可能な形式ならなんでも、
５）とにかくウェブに乗っけてくっつけよう

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