Atom 出版プロトコルを知る、第 1 回: Atom 出版プロトコルを使って Web リソースを作成し、編集する

Atom 出版プロトコルの基本的な操作を順を追って学ぶ

Atom 出版プロトコルは、コンテンツの公開と管理のための重要な新しい標準です。この記事では、このプロトコルの概要を上位レベルで説明し、また基本的な操作や機能について学びます。

James Snell (jasnell@us.ibm.com), Software Engineer, Emerging Technologies, EMC

James Snellは、IBMのEmerging Technologies Toolkitチームの一員です。過去2年間は、新興のWebサービス技術や標準などに焦点を当てており、またAtom 1.0仕様にも貢献しました。新興技術に焦点を当てたウェブログ、http://www.ibm.com/developerworks/blogs/page/jasnellを維持管理しています。



2006年 10月 17日

ここ数年、インターネット上でも、またファイアーウォールの内側でも、Web コンテンツのシンジケーション技術が非常に重要なものとなってきました。2005 年の 7 月、IETF (Internet Engineering Task Force) の Atom Publishing Format and Protocol Working Group (略して「atompub」として知られています) は、「ウェブログやオンライン・ジャーナル、ウィキ、その他類似のコンテンツといった Web リソースの、表示のためのフィード・フォーマットと、編集のためのプロトコル」を提供する 2 つの標準の仕様のうち、最初の方を公開しました。Atom 配信フォーマット (Atom Syndication Format: 一般には Atom 1.0 として知られています) は、それ以来何百万もの Web サイトにデプロイされ、今や市場の主なシンジケーション・プラットフォームのすべてでサポートされます。そして 1 年と少したった現在、2 つの仕様のうちの 2 番目、Atom 出版プロトコル (Atom Publishing Protocol) の標準化作業が間もなく完了しようとしています。

Atom 出版プロトコルは、Web リソースを作成し、編集するための、HTTP ベースの手法です。このプロトコルは、ブログのエントリーやポッドキャスト、ウィキ・ページ、カレンダー・エントリーなどを表す Atom 1.0 Feed and Entry 文書のインスタンスを、HTTP プロトコルによる基本的な操作 (GET や PUT、DELETE など) を使って渡し合うという考え方の元に設計されています。

これから先では、このプロトコルの入門としての基本的な操作を、順を追って説明します。ここでは、Atom 1.0 Syndication Format を使ったコンテンツ・シンジケーションと HTTP の基本をよく理解しているという前提で説明を進めます。この記事を読み進むにあたっては、Atom 1.0 (RFC 4287) と HTTP 1.1 (RFC 2616) の仕様のコピーを手元に置き、それを参照しながらさまざまな要素や方法についての説明と対応させるようにお勧めします。もし Atom フォーマットに慣れていない場合には、昨年私が developerWorks に寄稿した記事、「Atom 1.0 Syndication Formatの概要」 (「参考文献」を参照) に目を通すようにお勧めします。

上位レベルでの概要

Atom 出版プロトコルの中心にあるのは、Atom 1.0 Feed and Entry 文書で表現される編集可能リソースのコレクションという概念です。コレクションには固有の URI があります。この URI に対して HTTP の GET リクエストを発行すると、Atom Feed Document が返されます。クライアントがそのフィードの中に新しいエントリーを作成するには、そのコレクションの URI に HTTP の POST リクエストを送ります。こうして新たに作成されたエントリーには、それぞれ固有の Edit URI が割り当てられます。クライアントがこうしたエントリーを変更するには、単純にコレクションからリソースを取得し、変更を加えて戻します。フィードからエントリーを削除するには、適切な Edit URI に HTTP の DELETE リクエストを発行するだけです。すべての操作は単純な HTTP リクエストを使って行われ、通常の操作には単純なテキスト・エディターやコマンド・プロンプトで十分です。

図 1. Atom 出版プロトコルは単純な HTTP メソッドを使ってコンテンツを公開、管理する
図 1. Atom 出版プロトコルは単純な HTTP メソッドを使ってコンテンツを公開、管理する
リスト 1. オープンソースの curl HTTP クライアントを使って Atom 出版エンドポイントと対話動作を行う
curl -s -X POST --data-binary @entry.xml http://example.org/atom/entries
curl -s -X GET http://example.org/atom/entries/1
curl -s -X PUT --data-binary @entry.xml http://example.org/atom/entries/1
curl -s -X DELETE http://example.org/atom/entries/1

入手可能なコレクションを発見する

APP 対応のサービスを使うための最初のステップは、どんなコレクションが入手可能か、そうしたコレクションにどんなタイプのリソースが含まれているかを判断することです。Atom プロトコル仕様では、サービス文書として知られる XML フォーマットが定義されており、クライアントはこのフォーマットを使ってエンドポイントをイントロスペクトします。

サービス文書を取得するには、そのサービス文書の URI に HTTP の GET リクエストを送ります。

リスト 2. サーバーから APP サービス文書を取得する
GET /servicedocument HTTP/1.1
Host: example.org

サーバーは、クライアントが利用できるコレクションを列挙したサービス文書で応答する必要があります (リスト 3)。

リスト 3. 単純な APP サービス文書
HTTP/1.1 200 OK
Date: ...
Content-Type: application/atomserv+xml; charset=utf-8
Content-Length: nnn

<service xmlns="..." xmlns:atom="http://www.w3.org/2005/Atom">
<workspace>
<atom:title>My Weblog</atom:title>
<collection href="http://www.example.org/blog/entries">
<atom:title>Entries</atom:title>
<accept>entry</accept>
</collection>
<collection href="http://www.example.org/blog/photos">
<atom:title>Photos</atom:title>
<accept>image/*</accept>
</collection>
</workspace>
</service>

サービス文書の中にリストされた各コレクション要素は、コンテンツの一部を保存できるコンテナーを表します。サービス文書の中のワークスペース要素は、関連したコレクションを論理的にまとめるためにのみ使われます。例えば、1 人のユーザーが、ブログのエントリーやアップロードされたファイル、ブックマークなどに対して別々のコンテナーを提供するブログ・サービスに対して、複数のアカウントを持っているとします。こうした場合、それぞれのサービスを、サービス文書の中の別々のワークスペースとして表現することができます。

collection 要素は、コレクションのアドレス (href 属性) と、コレクションに追加できるコンテンツ・タイプ (accept 要素の mime タイプで識別されます) のリストを提供します。リスト 3 の例には、Atom Entry Document のみを受け付けるコレクションと、画像ファイル (PNG やGIF、JPEG など) のみを受け付けるコレクション、という 2 つのコレクションがあります。


コレクションにエントリーを追加する

コレクションのアドレスがわかったら、HTTP の POST メソッドを使って新しいリソースを追加します (リスト 4)。

リスト 4. APP コレクションにエントリーをポストする
POST /blog/entries HTTP/1.1
Host: www.example.org
Content-Type: application/atom+xml; charset=utf-8
Content-Length: nnn

<?xml version="1.0" ?>
<entry xmlns="http://www.w3.org/2005/Atom">
<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>
<author><name>James</name></author>
<summary>Some text.</summary>
</entry>

リスト 4 の例では、Atom Entry Document を、http://example.org/blog/entries にあるコレクションに追加しています。このコレクションの URI は、リスト 3 のサービス文書から取り出されます。ポストされるエントリーは有効なものでなければならないことに注意してください。つまり、ID や作者、更新要素などを持っている必要があります (ただし多くの APP サーバーは、クライアントが提供する値を無視し、上書きするようにしています)。

POST リクエストが成功すると (リスト 5)、その応答として、クライアントには 2 つの重要な情報が提供されます。つまりリクエストの状態 (HTTP のレスポンス・コード) と、Location ヘッダーに含まれる、作成されたばかりのリソースのアドレスの 2 つです。

リスト 5. POST 操作が成功した場合のレスポンス
HTTP/1.1 201 Created
Date: nnnn
Content-Type: application/atom+xml; charset=utf-8
Content-Location: /blog/entries/1
Location: /blog/entries/1
ETag: "/blog/entries/1?1"
Last-Modified: Sat, 12 Aug 2006 13:40:03 GMT

<?xml version="1.0" ?<
<entry xmlns="http://www.w3.org/2005/Atom" >
<id>tag:example.org,2006:/blog/entries/1</id>
<title>Atom-Powered Robots Run Amok</title>
<link href="http://example.org/2003/12/13/atom03"/>
<link rel="edit" href="http://example.org/blog/entries/1" />
<updated>2006-08-12T13:40:03Z</updated>
<author><name>James M Snell</name></author>
<summary>Some text.</summary>
</entry>

一部の APP サーバーはエントリーのさまざまな重要側面 (例えば ID や作者、更新要素など) を変更できるため、サーバーが返すレスポンスには、実際にコレクションに追加されたエントリーのコピーが含まれている場合があります。これによってクライアントは、サーバーに送信したエントリーと実際に作成されたエントリーとを照合することができます。

コレクションの中のエントリーをリストする

コレクションにエントリーが追加されると、クライアントはそのコレクションの URI に GET リクエストを発行することで、そのコレクションのメンバー・リソース・リストを取得することができます (リスト 6)。

リスト 6. コレクション・フィードを取得する
GET /blog/entries HTTP/1.1
Host: example.org

このリクエストへのレスポンスは Atom Feed Document であり、この文書の中の各エントリーのセットが、コレクションの中の 1 つのメンバー・リソースを表します (リスト 7)。

リスト 7. APP Collection に対する Atom Feed Document
HTTP/1.1 200 OK
Date: ...
Content-Type: application/atom+xml; charset=utf-8
Content-Length: nnn
ETag: "/blog/entries?132"
Last-Modified: Sat, 12 Aug 2006 13:40:03 GMT

<feed xmlns="http://www.w3.org/2005/Atom" 
xml:base="http://example.org/blog/entries">
<id>http://example.org/blog/entries</id>
<title>My Blog Entries</title>
<updated>2006-08-12T13:40:03Z</updated>
<link rel="self" href="/blog/entries" />
<link href="http://blog.example.org" />
<entry>
<id>tag:example.org,2006:/blog/entries/1</id>
<title>Atom-Powered Robots Run Amok</title>
<link href="http://example.org/2003/12/13/atom03"/>
<link rel="edit" href="http://example.org/blog/entries/1" />
<updated>2006-08-12T13:40:03Z</updated>
<author><name>James</name></author>
<summary>Some text.</summary>
</entry>
<entry>
...
</entry>
...
</feed>

コレクションが返すフィードは、そのコレクションに対する一種のインデックスのように考えることができます (ファイルシステムに対して「dir」や「ls」コマンドを実行するようなものです)。

エントリー自体は、最新の更新を先頭に、各エントリーの更新要素の値に従って並べられています。またエントリーのリストは、いわゆるページ・リンクを使って相互リンクされた、複数の Atom Feed Document にまたがる可能性があります (リスト 8)。

リスト 8. ページ・リンクが使われていることを示すフィードのスニペット
<feed xmlns="http://www.w3.org/2005/Atom" 
xml:base="http://example.org/blog/entries?page2">
<link rel="next" href="entries?page3" />
<link rel="previous" href="entries?page1" />
...

コレクション・メンバー・リソースのリストが大きくなりすぎる可能性のある場合にも、ページ・リンクを使うことによって、小さな、管理が容易なサブセットに分割することができます。


エントリーを編集する

クライアントがエントリーを編集するためには、まず編集可能な表現を取得する必要があります。そのためには、メンバーの Edit URI に GET リクエストを発行します (リスト 9)。これは基本的に、文書を編集する前にローカルのテキスト・エディターで文書を開くことに対応します。

リスト 9. リソースの編集可能な表現を取得する
GET /blog/entries/1 HTTP/1.1
Host: example.org

このリクエストに対するレスポンスは Atom Entry Document である必要があります (リスト 10)。

リスト 10. 編集可能リソースを表現する Atom Entry Document
HTTP/1.1 200 OK 
Date: nnn
Content-Type: application/atom+xml; charset=utf-8
Content-Length: nnn
ETag: "/blog/entries/1?1"
Last-Modified: Sat, 12 Aug 2006 13:40:03 GMT

<?xml version="1.0" ?>
<entry xmlns="http://www.w3.org/2005/Atom" >
<id>tag:example.org,2006:/blog/entries/1</id>
<title>Atom-Powered Robots Run Amok</title>
<link href="http://example.org/2003/12/13/atom03"/>
<link rel="edit" href="http://example.org/blog/entries/1" />
<updated>2006-08-12T13:40:03Z</updated>
<author><name>James</name></author>
<summary>Some text.</summary>
</entry>

クライアントは編集可能な表現を受信すると、選択したエントリーに対して (妥当な範囲内で) 必要な変更を加え、次にエントリーの Edit URI に PUT リクエストを発行して更新します (リスト 11)。

リスト 11. 変更され、サーバーに送信される Atom エントリー
PUT /blog/entries/1 HTTP/1.1
Host: example.org
Content-Type: application/atom+xml; charset=utf-8
Content-Length: nnnn
If-Match: "/blog/entries/1?1"
If-Unmodified-Since: Sat, 12 Aug 2006 13:40:03 GMT

<?xml version="1.0" ?>
<entry xmlns="http://www.w3.org/2005/Atom" >
<id>tag:example.org,2006:/blog/entries/1</id>
<title>Atom-Powered Robots Run Crazy</title>
<link href="http://example.org/2003/12/13/atom03"/>
<link rel="edit" href="http://example.org/blog/entries/1" />
<updated>2006-08-12T13:40:03Z</updated>
<author><name>John</name></author>
<summary>Some different text.</summary>
</entry>

PUT リクエストの中で If-Match ヘッダーと If-Unmodified-Since ヘッダーが使われていることに注意してください。これらのヘッダーはオプションですが、これらを使うことによって APP 実装は、他のクライアントがメンバー・リソースに加えた変更を上書きされるのを防ぐことができます。もし、いずれかの条件に合致しない場合には、サーバーはリクエストを拒否し、クライアントが変更しようとするリソースに競合があった可能性があることを、そのクライアントに通知する必要があります。もし両方の条件に合致し、クライアントが送信した変更が受け入れ可能なものだとサーバーが判断すると、サーバーは適切な成功レスポンスで応答します。


エントリーを削除する

クライアントがコレクションからリソースを削除するためには、Edit URI に対して DELETE リクエストを送ります (リスト 12)。

リスト 12. コレクションからリソースを削除する
DELETE /blog/entries/1 HTTP/1.1
Host: example.org

削除が成功すると、そのエントリーは Atom フィードのコレクションの中に現れなくなり、編集もできなくなります。


コレクションにメディア・リソースを追加する

写真や文書、録音した音声など、任意のメディア・リソースを APP コレクションに追加することもできます。そうしたアイテムは、APP の仕様ではメディア・リンク・エントリーと呼ばれます。こう呼ばれる理由は、こうしたリソースがコレクションに追加されると、クライアントがポストしたメディア・リソースにリンクされた Atom エントリー文書をサーバーが作成するためです。

これは、元々は単にウェブログの作者たちが、彼らのポストに含めるかもしれないメディア・オブジェクトをアップロードできるようにするためのものでしたが、Atom 出版プロトコルで任意のメディア・リソースがサポートされたことによって、このプロトコルは下記を含む広範なアプリケーションに最適なものとなりました。

  • ポッドキャスト
  • ビデオ・ブログ
  • フォト・ライブラリー
  • ウィキと状況依存型アプリケーション
  • 文書管理
  • XML リポジトリー
  • ソフトウェア配布
  • 生産性アプリケーション (Office Suites など)
  • その他の多種多様なアプリケーション

クライアントがメディア・リンク・エントリーを作るためには、コレクション URI に POST リクエストを発行しますが、そこに Atom Entry Document 文書を含めるのではなく、リンクされるメディア・リソースの表現を含めるのです (リスト 13)。

リスト 13. APP コレクションにバイナリー画像ファイルをポストする
POST /blog/photos HTTP/1.1
Host: example.org
Content-Type: image/png
Content-Length: nnnn
Slug: A trip to the beach

{binary image data}

もしコレクションが、クライアントが送信したタイプのメディア・リソースを保存できる場合は、コレクションはそのメディア・リソースを保存し、そのメディア・リソースにリンクする Atom Entry Document を作成します (リスト 14)。リクエストの中に含まれている Slug ヘッダーは Atom 出版仕様 (Atom Publishing Specification) で導入された新しい HTTP Entity Header であり、メンバー・リソースに単純な名前を関連付けるために使われます。この名前は、そのリソースを作成し、管理する際のさまざまな目的に使うことができます。例えばサーバーは、メンバー・リソースの URI を作成する際に、あるいは Atom Entry Document のタイトル要素の値を設定する際に slug の値を使うことができます。Slug ヘッダーは、Atom エントリーやメディア・リソースをポストする際に使われますが、最も頻繁に使われるのは後者の場合です。

リスト 14. メディア・ポストへのレスポンスとして作成されるメディア・リンク・エントリー
HTTP/1.1 201 Created
Date: nnnn
Content-Location: /blog/photos/a_trip_to_the_beach
Location: /blog/photos/a_trip_to_the_beach
Content-Type: application/atom+xml; charset=utf-8
Content-Length: nnnn
Slug: A trip to the beach
ETag: "/blog/photos/a_trip_to_the_beach?1"
Last-Modified: Sat, Aug 12 2006 14:11:04 GMT

<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
<id>tag:example.org,2006:/blog/photos/a_trip_to_the_beach</id>
<title>A trip to the beach</title>
<link rel="edit" 
href="http://example.org/blog/photos/a_trip_to_the_beach" />
<link rel="edit-media" type="image.png" 
href="http://example.org/blog/photos/a_trip_to_the_beach?media" />
<updated>2006-08-12T14:11:04Z</updated>
<author><name>James</name></author>
<summary>A trip to the beach</summary>
<content type="image/png" 
src="http://blog.example.org/photos/a_trip_to_the_beach" />
</entry>

メディア・リンク・エントリーには必ずコンテンツ要素が含まれており、その src 属性には作成されたメディア・リソースの URI が提供されています。この URI を、そのメディア・リソースを公開参照するために使うことを考えてみてください。これとは別のエディット・メディア・リンクと組み合わせることによって、メディア・リソースの更新に使用する URI を特定することができます。


メディア・リソースを編集する

コレクションにポストされたメディア・リソースの編集は、基本的に Atom エントリーの編集と同じです。最初のステップは、エディット・メディア・リンクで指定される URI に GET リクエストを発行し、そのリソースの編集可能な表現を取得することです (リスト 15)。

リスト 15. メディア・リソースの編集可能な表現を取得する
GET /blog/photos/a_trip_to_the_beach?media HTTP/1.1
Host: example.org

編集可能な表現が返されたら、クライアントは選択されたすべての変更を加え、そしてエディット・メディア URI に対して PUT リクエストを発行します (リスト 16)。

リスト 16. メディア・リソースを変更する
PUT /blog/photos/a_trip_to_the_beach?media HTTP/1.1
Host: example.org
Content-Type: image/png
Content-Length: nnn

{new binary image data}

コレクションを保護する

Atom 出版プロトコルは実装が認証を使うように要求していませんが、悪意のクライアントがコレクション・メンバーを作成したり変更したりするのを防ぐために、ぜひとも認証を使うべきです。実装は、最低限 HTTP の Basic 認証とTLS/SSL 接続を使える必要があります。しかし実際には、APP クライアントは様々な認証機構を想定すべきでしょう。どのような種類の認証が使われているとしても、サーバーは標準の HTTP スタイルのチャレンジを利用して、選択された認証タイプを識別できる必要があります。

例えば、もしサーバーがクライアントからの無許可リクエストを受信した場合には、サーバーは WWW-Authenticate ヘッダーを含んだ 401 Unauthorized レスポンスで応答する必要があります (リスト 17)。

リスト 17. 無許可リクエストへのレスポンス
HTTP/1.1 401 Unauthorized
Date: nnn
WWW-Authenticate: Basic realm="my blog"

そうするとクライアントは、適切な Authorization ヘッダーを持ったリクエストを発行し直します。

リスト 18. 認証されたリクエスト
POST /entries/blog HTTP/1.1
Host: example.org:443
Authorization: Basic SmFtZXM6bm90IG15IHJlYWwgcGFzc3dvcmQgOi0p
...

APP を活用する

ここまで、Atom 出版プロトコルの基本的な操作を、その中核機能のすべてについて例を示しながら説明してきました。ただし、Atom 出版プロトコルを活用するための方法については説明しませんでした。このシリーズの次回の記事では、このプロトコルの活用と考えられるいくつかのアプリケーションのシナリオを順を追って説明します。そうしたシナリオには、ウェブログやソーシャル・ブックマーキング、フォト・アルバムなどの明白なアプリケーションを始め、あまり明白でははないアプリケーションとして、カレンダーや連絡先管理、文書やメディアのコンテンツ・リポジトリー、データベース管理、状況依存型アプリケーション、さらにはサービス指向アーキテクチャーなどもあります。

その後は、現在 Apache Software Foundation で育成中の Apache Abdera (Atom を実装したオープンソース) を使って、Atom 出版 (Atom Publishing) のクライアントとサーバーを Java で実装する方法を探り、また APP 対応アプリケーション・サービスの作成についても解説する予定です。

参考文献

学ぶために

  • コンテンツの公開と管理のための新しい標準、Atom 出版プロトコルの仕様の詳細を見てください。
  • Atom 配信フォーマットの仕様の詳細を見てください。ウェブログやニュース・ヘッドラインなどの Web コンテンツを Web サイトに、そして直接ユーザー・エージェントに配信するフィードを記述した、この XML ベースの文書フォーマットが詳述されています。
  • Atom 1.0 Syndication Formatの概要」 (James Snell 著、developerWorks、2005 年 8 月) を読んでください。Atom が他のシンジケーション・フォーマットに比べて技術的な強みがあることを解説し、また、効果的な使い方の例をいくつかあげています。
  • Atom 出版プロトコルで活用されている HTTP (Hypertext Transfer Protocol ) の仕様、HTTP v1.1 を見てください。
  • HTTP response status codes を調べ、どんな方法に従うのか、またレスポンスに必要なメタ情報などを含めて、標準のステータス・コードについて学んでください。
  • Editing the Web を調べ、HTTP の entity タグを使って同時更新を検出する方法について学んでください。
  • Apache Abdera project を調べ、Atom 対応の Java アプリケーションを開発してください。
  • Wordpress Weblog を読み、皆さんのウェブログに Atom 出版プロトコルのサポートを追加してください。
  • Google's implementation を調べ、Atom 出版プロトコルを使う Google Data API について学んでください。
  • XML および関連技術において IBM 認証開発者になる方法についてはこちらを参照してください。
  • XML 記事一覧 を利用してください。developerWorks XML ゾーンには、広範な話題を網羅した技術記事やヒント、チュートリアル、技術標準、IBM レッドブックなどが用意されています。
  • developerWorks technical events and webcasts で最新情報を入手してください。

製品や技術を入手するために

  • 皆さんの次期開発プロジェクトを、IBM trial software を使って構築してください。developerWorks から直接ダウンロードすることができます。

議論するために

  • XML zone discussion forums に参加してください。これらのフォーラムでは、XML を中心に議論が行われています。
  • developerWorks blogs から developerWorks のコミュニティーに加わってください。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=XML, Web development
ArticleID=239917
ArticleTitle=Atom 出版プロトコルを知る、第 1 回: Atom 出版プロトコルを使って Web リソースを作成し、編集する
publish-date=10172006