昨日は RPC ベースである Web サービスを紹介した。
基本的には、オブジェクトのメソッド呼び出しを
HTTP を利用してカプセル化したものであった。

それに対し、Web 上のデータに対する処理を、
全く別の視点から捉えたものに、
REST (Representational State Transfer) がある。

RPC では、オブジェクトの操作がメインであるため、
「メソッド呼び出し」を HTTP で表現した。
つまり、操作対象はオブジェクトであり、
オブジェクト指向のデータカプセル化の原則が存在する。

REST では、Web 上にあるデータそのものにアクセスする。
いわば、データベースに対する問い合わせに近い感覚である。
SQL を HTTP 基盤上に載せたような感じだ。

REST は、HTTP の特性を活かしているため、
HTTP の機能に依存している部分がある。

HTTP には GET の他に、POST, PUT, DELETE などの
メソッドがあるが、REST ではそれらを利用し、
名前どおり、取得、追加、更新、削除などの操作を行う。
将に、データベースの CRUD 特性に近い機能だ。

また、REST には、Web 上のあらゆるデータには、
一意の URI (URL) が存在するという原則がある。

REST では HTTP のメソッドで操作を表現し、
通信される本体は、原則としてデータのみとなる。
取得時に SQL の WHERE 節のような絞込みが必要であれば、
URI のクエリパラメータを利用して表現する。

あらゆるデータを取得するために、
それに対応した URI が存在するため、
それをブックマークすることも容易であり、
問い合わせには、HTML フォームもそのまま利用できる。
そのため、Web 開発者との相性が非常に良い。

REST のモデルに基づいた Web サーバから、
欲しいデータを取得するためには、
純粋に URI を指定して GET を発行するだけで良いのだ。
取得メソッド用の XML を作成して送信する必要がある、
Web サービスと大きく異なる点である。

さて、REST は概念であり思想であり設計であるが、
そのデータの表現に対して具体的な決まりはない。
つまり、HTML でも XML でもバイナリでも構わず、
XML の要素内容に関する決まりなども存在しない。
これらは、設計者が考えることである。

ただ、REST では、データの表現に対して、
データそのものの情報だけでなく、
他のデータに移動する「状態遷移」のための情報を
持たせることを要求している。
これは、HTML のハイパーリンクのような表現のことだ。

そのため、REST においても、
データの表現には XML を利用することが多く、
他のデータと関連するデータを取得した場合は、
その XML 中に関連するデータを示す URI を含むことで、
URI を辿るだけで次々とデータにアクセスができる。

これは、データベースで言うところの、
リレーションシップのような感じだろうか。

REST を説明するのは難しいが、
HTTP + HTML から、デザイン的な表現を撤廃し、
HTTP + XML へと発展させたものと考えることができる。

最近では、REST も Web サービスの一部と考えられており、
Amazon や Yahoo といった大手 Web サイトが、
REST ベースの情報サービスを提供している。