Web APIの次世代標準プロトコル「Atom Publishing Protocol」

第2回 AtomPubにおけるリソース操作 - CRUD

この記事を読むのに必要な時間:およそ 5.5 分

メディアリソースの操作

メンバリソースの中でもXML形式のエントリで表現できないようなデータ(典型的な例は画像データ)はメディアリソースと呼ばれます表4)⁠

表4 メンバリソースの種類

メンバリソースの種類内容
エントリリソースAtom Entryで表現されるデータ
メディアリソース(通常は)Atom Entryで表現できないデータ

メディアリソースを扱う場合,リソースをエントリとして表現するために「メディアリンクエントリ」と呼ばれるエントリリソースが用意されます。

そしてこのエントリリソースからはメディアリソースへのリンクが張られます(atom:linkエントリで表現され,メディアリンクエントリ内に保持されます)⁠

以下にCRUD操作を紹介しますが,いずれも図中の点線でかかれているリソースがメディアリソース,実線のリソースがエントリリソース(メディアリンクエントリ)⁠伸びている矢印はメディアリンクエントリ内にあるatom:link要素を表現しています。

取得

メディアリソースをGETした場合は,エントリ文書以外のメディアタイプで実際のリソースを取得することができるでしょう。

図6 メディアリソースを取得する

図6 メディアリソースを取得する

追加

コレクションに対してメディアリソースをPOSTした場合は,メディアリソースおよびメンバエントリ(メディアリンクエントリ)が作成されます。メディアリンクエントリはメディアリソースのメタ情報を表現するメンバリソースとなります。

図7 メディアリソースを追加する

図7 メディアリソースを追加する

更新

メディアリソースを更新したい場合は,メディアリソースのURIを,メタ情報を更新したい場合は,メディアリンクエントリのURIに対してPUTを適用します。

図8 メディアリソースを更新する

図8 メディアリソースを更新する

図9 メディアリンクエントリを更新する

図9 メディアリンクエントリを更新する

削除

エントリリソース(メディアリンクエントリ)を消去した場合は,対応するメディアリソースも削除されるべきであると規定されています。このため多くのサーバではメディアリソースも同時に削除されてしまうことになるでしょう。図中の /member/1 を削除した場合は同時に /member/2 も削除されてしまうでしょう。

また,メディアリソースを削除した場合は,メディアリソースが削除されます。このとき対応するエントリリソース(メディアリンクエントリ)も多くの場合,削除されるでしょう(厳密に言えばこの場合も実装依存になっています)⁠

図10 メディアリンクエントリを削除する

図10 メディアリンクエントリを削除する

図11 メディアリソースを削除する

図11 メディアリソースを削除する

サービス文書

それではどのように,Webリソースを操作するURIを取得するのでしょうか?

それを解決してくれるのがサービス文書です。サービス文書を取得することがクライアントにとってAtomサーバの提供しているサービスを知ることができる唯一の方法です。

通常,クライアント側にはサービス文書を取得するためのURI(サービス文書URI)をなんらかの方法によって伝えます。このURIをGETすることによってクライアント側は様々なURIを知ることになります。

では実際にどのようなものかみてみましょう。

サービス文書の例(RFC 4287より抜粋)

<?xml version="1.0" encoding='utf-8'?>
<service xmlns="http://www.w3.org/2007/app" xmlns:atom="http://www.w3.org/2005/Atom">
  <workspace>
    <atom:title>Main Site</atom:title>
    <collection href="http://example.org/blog/main">
      <atom:title>My Blog Entries</atom:title>
      <categories href="http://example.com/cats/forMain.cats" />
    </collection>
    <collection href="http://example.org/blog/pic">
      <atom:title>Pictures</atom:title>
      <accept>image/png</accept>
    </collection>
  </workspace>
</service>

サービス文書は,ルート要素がapp:service要素である文書です。

app:service要素は一つ以上のapp:workspace要素から構成されています。

app:workspace要素には,atom:title要素が必ず一つ含まれています。またapp:collection要素が0個以上含まれています。workspaceについてはcollectionを束ねるものとしか定義されておらず,あまり意味はありません。ここではcollectionに注目していきます。

app:collection要素のhref属性は,そのコレクションのURIを表現しています。

ここに記載されているURIに対してPOSTやGETができます。

app:collection要素はapp:accept要素を持つことができます。app:accept要素は,そのコレクションがPOSTを受け付けることができるファイルタイプを示しており,RFC 2616で定義されているmedia-rangeの内容を指定できます。

この要素が省略された場合はAtomエントリ文書のみが受け付け可能と解釈されるべきであると規定されています。また,空要素(<accept></accept>)のみが現れている場合は,何も受け付けられないと解釈するべきであると規定されています。

全てのファイル形式が受け付け可能な場合は<accept>*/*</accept>という表現が利用できます。

上記の例では,My Blog Entriesコレクションに対しては,エントリ文書を登録することができます。また,Picturesというコレクションに対してはPNG形式の画像ファイルのみが登録できると解釈することができます。

さて,次回はこのサービス文書を手がかりに,リソースへのCRUD操作を追っていくことにしましょう。

著者プロフィール

朝倉浩志(あさくらひろし)

NTTコミュニケーションズ 先端IPアーキテクチャセンタ リサーチエンジニア。上位層プロトコル及びWebテクノロジの技術開発に取り組む。

コメント

コメントの記入