初出: 技術評論社刊『WEB+DB PRESS』Vol.32

さて、これまでは Web アプリケーションの視点から REST を眺めてきましたが、REST が本領を発揮するのは Web サービスの分野となります。特に、ブラウザ以外のクライアントに向けてサービスを公開するとき、REST はとても参考になるでしょう。

PUT/DELETE で CRUD が揃う

統一インターフェースの項で「GET や POST やその他の HTTP メソッド」と書きました。現在の Web ブラウザの実装で主に使われている GET と POST 以外にも HTTP ではいくつかのメソッドが用意されています。その中でも重要なのが PUT と DELETE です。 PUT はリソースを更新するためのメソッドです。DELETE はリソースを削除するためのメソッドです。また、GET はリソースを取得するメソッドで、POST はリソースを新規に作成するメソッドとなります。この四つのメソッドでい　わゆる CRUD 操作を実現できます(表1)。重要なのはこれらのメソッドで、ほとんど全てのリソース操作が行えるようになることです。この四メソッドを上手に利用しているのが、次に紹介する AtomPub というプロトコルです。

メソッド	CRUD	意味	POST	Create	新規作成
GET	Read	取得
PUT	Update	更新
DELETE	Delete	削除

Atom Publishing Protocol

現在 blog の編集は通常ブラウザのフォームを使って行われています。この方式は汎用的で良い面もあるのですが、一方でユーザビリティが悪くて使いづらいものです。ブラウザの操作を誤って blog の記事を消してしまった、という経験がある方も多いのではないでしょうか。 このような状況を解決しようと、blog 編集の専用クライアントとプロトコルの開発が進められてきました。いくつかの独自実装が存在しますが、その決定版とも言えるのが RFC 5023 Atom Publishing Protocol (AtomPub)です。 AtomPub は前項で説明した四つの HTTP メソッドを最大限活用して、blog の編集を行うように設計されています。各記事がそれぞれリソースとなり、そのリソースを投稿したり編集したり削除したり取得したりできるのです。 以下では AtomPub を例に、REST に基くリソース編集の実際を見ていきたいと思います。

AtomPub のリソースモデル

AtomPub のリソースモデルが図1になります。一つの blog は複数の記事からなるコレクションとして表わされます。コレクションは記事一覧リソースと捉えるとわかりやすいでしょう。コレクションからは各記事(エントリ)リソースにリンクが張られています。

図1 AtomPP のリソースモデル

各リソースは表2のような URI を持つこととします(AtomPub では URI の形式は定めていません。ここでは AtomPub の一実装形態を解説します。)。

リソース	URI	記事一覧	http://example.com/list
記事	http://example.com/entry/{記事ID}

{記事ID} の部分は各エントリの ID と考えましょう。 各リソースには表3のような HTTP メソッドが適用できます。

リソース	メソッド	効果	エントリ	GET	記事の取得
エントリ	PUT	記事の更新
エントリ	DELETE	記事の削除
コレクション	GET	記事一覧の取得
コレクション	POST	記事の新規作成

記事一覧の取得 (GET)

まず、記事一覧を取得してみましょう。記事一覧の URI は http://example.com/list ですので、HTTP リクエストは以下のようになります。

GET /list HTTP/1.1

Host: example.com

リクエストが成功した場合、レスポンスは以下のようになります。

HTTP/1.1 200 OK
Content-Type: application/atom+xml<feed xmlns="http://www.w3.org/2005/Atom">

  <title>日記一覧</title>
  <entry>
    <title>REST入門</title>
    <link href="/entry/0" />
  </entry>
  <entry>
    <title>今日の出来事</title>
    <link href="/entry/1" />
  </entry>

  …
</feed>

このレスポンスは Atom フィードになります。feed 要素内の各 entry 要素のlink 要素で、各記事へのリンクが貼られています。

記事の取得 (GET)

次に最初の link 要素でリンクされている記事を取得してみましょう。URI はhttp://example.com/entry/0 になるのでリクエストは以下のようになります。

GET /entry/0 HTTP/1.1
Host: example.com

リクエストが成功した場合、レスポンスは以下のようになります。

HTTP/1.1 200 OK
Content-Type: application/atom+xml; type=entry<entry xmlns="http://www.w3.org/2005/Atom">

  <title>REST 入門</title>
  <updated>2005-11-24T23:01:01</updated>
  <content>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <p>RESTは …</p>
    </div>
  </content>
</entry>

記事の更新 (PUT)

次はこの記事の内容を更新してみましょう。更新したい記事リソースに対してPUT メソッドを適用します。

PUT /entry/0 HTTP/1.1
Host: example.com
Content-Type: application/atom+xml; type=entry
Authorization: Basic eW9oZWk6aG9nZQ==

<entry xmlns="http://www.w3.org/2005/Atom">
  <title>REST 入門</title>
  <updated>2005-11-24T23:01:01</updated>
  <content>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <p>RESTとは …</p>
    </div>
  </content>
</entry>

Authorization ヘッダを使っていることに注意してください。この例では記事の編集を行えるのは限られたユーザという設定にしました。そのため、ここでは Basic 認証を行っています。 更新が成功すれば、以下のレスポンスが返ります。

HTTP/1.1 200 OK

記事の削除 (DELETE)

次に、記事を削除してみましょう。記事の削除は HTTP の DELETE メソッドで行います。

DELETE /entry/0 HTTP/1.1
Host: example.com
Authorization: Basic eW9oZWk6aG9nZQ==

先程の PUT メソッドに続いて、ここでも再び Authorization ヘッダを使っていることに注意してください。削除も認証が必要な操作なので、このリクエストにも認証情報を含めています。このように、認証情報や Host ヘッダ等、このメッセージを処理するのに必要な情報を全て含めるのが自己記述的メッセージの特徴です。 削除が成功すれば、以下のレスポンスが返ります。

HTTP/1.1 200 OK

記事の新規登録 (POST)

最後に、一旦削除した記事を再登録してみましょう。ここでは同一内容の新規記事の登録で再登録を実装します。 これまでの例では、リソースの URI に対してHTTP の GET/PUT/DELETE メソッドを適用してきました。しかし、新規に登録する記事には URI がありません。AtomPub では、記事一覧リソースに新規記事の XML を HTTP POST することで、これを実現しています。

POST /list HTTP/1.1
Host: example.com
Authorization: Basic eW9oZWk6aG9nZQ==<entry xmlns="http://www.w3.org/2005/Atom">
  <title>REST 入門</title>
    <div xmlns="http://www.w3.org/1999/xhtml">
      <p>RESTとは …</p>
    </div>
</entry>

新規登録が成功すると、以下のレスポンスが返ります。

HTTP/1.1 201 Created
Location: http://example.com/entry/4

HTTP のステータスコードが 201 になっているのに注意してください。201 はCreated すなわち、新しいリソースが新規に作成されたことを示します。この新リソースの URI が Location ヘッダに入ります。

AtomPub の可能性

さて、この AtomPub はもともと blog 編集用のものでしたが、実は blog 編集以外にも応用されています。たとえばオンラインカレンダーサービスのlogly カレンダーでは自分のスケジュールの投稿・編集 APIとして AtomPub が採用されています。このように AtomPub は REST アーキテクチャスタイルに基いた汎用コンテンツ編集プロトコルとしての可能性を秘めています。もしコンテンツ編集的側面を持った Web アプケーションがあったら、それを AtomPub で公開することができるかもしれません。

REST アーキテクチャスタイル

さて、ここまで REST の特徴を一つずつ見てきました。結局 REST って HTTP と URI のことなの? と思われた方もいるかもしれません。一言で言ってしまえば、そのとおりです。HTTP と URI というアーキテクチャの設計思想となっているのが REST なのです。その設計思想の中には、これまで見てきたように、統一インターフェース、階層化システム、ステートレスサーバなど、複数のスタイルがあります。そしてこれら複数のスタイルを組合せたアーキテクチャスタイルが REST です。 ではその設計思想を知っておくと何が嬉しいのでしょうか。それは HTTP やURI の正しい使い方がわかることです。HTTP や URI を正しく使えば、Web アプリケーションの性能が良くなったり、スケーラビリティが上ったり、セキュリティが向上したりします。 (次回に続きます)