REST

出典: フリー百科事典『ウィキペディア（Wikipedia）』

Representational State Transfer(REST) は、ウェブのような分散ハイパーメディアシステムのためのソフトウェアアーキテクチャのスタイルのひとつである。この語は2000年に、HTTPプロトコル規格の主要著者の一人であるRoy Fieldingが、ウェブについて書いた博士論文で初めて現れ、ネットワーキングコミュニティの中ですぐに広く使われることになった。

RESTは、初めはアーキテクチャの原則と制約の集まり(後述)を指していたが、次第に、XMLやHTTPを使った簡易なウェブベースのインターフェイスのうち、WebサービスのSOAPプロトコルのような MEP（Message Exchange Pattern; SOAPノード相互のメッセージ交換のパターンを確立するための雛型）ベースの特別な抽象化をしないもののことを、大まかに意味する用語として使われるようになった。RESTは次に述べるように2つのやや異なる意味で使われている。

FieldingのRESTアーキテクチャスタイルの原則に合わせたWebサービスシステム。
RPCスタイルに合わせた簡易な XML+HTTP インターフェイスを採用したシステム(SOAPは使わない) 。

RESTはこのように2つのやや異なる意味で使われているため、技術的な議論の中で混乱を引き起こすことがある。ただし、RPCはRESTの実例とはいえない。

FieldingのREST原則に従うシステムは、しばしばRESTfulといわれる。RESTをとても熱心に支持する人々は自らのことをRESTafariansと呼ぶ。

[編集] 原則

REST を支持する人々は、ウェブのスケーラビリティと成長は、次に述べるような、いくつかのキーとなる設計原則の結果であると論じる。

ステートレスなクライアント/サーバープロトコル: HTTPメッセージの一つ一つが、そのリクエスト (メッセージ) を理解するために必要な全ての情報を含む。そのため、クライアントもサーバーも、メッセージ間におけるセッションの状態を記憶しておく必要がない。ただし実際には、多くのHTTPベースのアプリケーションはクッキーやその他の仕掛けを使ってセッションの状態を管理している (URLリライティングのような一部のセッション管理手法を使うシステムは、RESTful ではない) 。
すべての情報 (リソース) に適用できる「よく定義された操作」のセット: HTTP では操作 (メソッド) の小さなセットが定義されている。最も重要なのは "GET"、"POST"、"PUT"、"DELETE" である。これらはデータ永続化に要求される CRUD と比較されることがある。もっとも "POST" に関しては CRUD にはぴったり対応していない。
リソースを一意に識別する「汎用的な構文」: RESTful なシステムでは、すべてのリソースは URI (Uniform Resource Identifier) で表される一意的な (ユニークな) アドレスを持つ。
アプリケーションの情報と状態遷移の両方を扱うことができる「ハイパーメディアの使用」: RESTシステムでは、多くの場合、HTML または XML ファイルを使う。こうしたファイルに情報およびその他のリソースへのリンクを含める。こうすることにより、あるRESTリソースから他のRESTリソースを参照したい場合は単にリンクを辿るだけでよい。レジストリなどの他の基盤的な機能を使う必要はない。

[編集] リソース

REST において重要な概念は、「リソース」(情報の断片) である。個々のリソースは、グローバルな識別子 (URI) により参照することができる。リソースに対する操作は次のようにして行われる。

ネットワークの「コンポーネント」(クライアントやサーバ) が、標準化されたインターフェイス (HTTP) により通信する。
ネットワークを介してリソースの「表現」(representation) を交換する (実際にはファイルがアップロード・ダウンロードされる)。

しかし実際のところこうしたリソース操作は議論の対象となっている。一部の人々には「リソース」と「表現」とを区別することは観念的すぎるとの意見がある。ただし RDFコミュニティでは、リソースと表現の区別は、一般的に行われている。

さまざまな「コネクタ」(クライアント、サーバ、キャッシュ、トンネルなど) がリクエストを仲介することができる。ただしコネクタは過去のリクエストを参照せずに仲介することができなければならない。

これは REST の原則を構成する「レイヤリング」と呼ばれる制約である。レイヤリングは、情報アーキテクチャやネットワークアーキテクチャの他の多くの部分にも見られる一般的な設計原則でもある。

こうすることで、RESTアプリケーションは、次の2つの情報を認識することで、リソースを扱うことが可能である。

リソース識別子
要求されたリクエスト

アプリケーションと実際の情報を持つサーバとの間にある他のものについて意識する必要はない。つまりアプリケーションは、キャッシュやプロキシ、ゲートウェイ、ファイアーウォール、トンネルなどの有無を意識する必要は無い。

ただしアプリケーションは、返された情報 (表現) のフォーマットを理解できる必要がある。そのフォーマットは、多くの場合は何らかの HTML か XML の文書であるが、場合によっては画像やその他のコンテンツであることもある。

[編集] REST対RPC

RESTなウェブアプリケーションは、RPC (リモートプロシージャコール) アプリケーションとは異なる設計面のアプローチを必要とする。RPC では、プロトコル操作 (動詞) の多様性を重視する。RPCアプリケーションが定義する操作の例を次に示す。

getUser()
addUser()
removeUser()
updateUser()
getLocation()
addLocation()
removeLocation()
updateLocation()
listUsers()
listLocations()
findLocation()
findUser()

一方 REST では、リソース (名詞) の多様性を重視する。RESTアプリケーションが定義するリソースの型の例を次に示す。

 User {}
 Location {}

それぞれのリソースは、http://www.example.org/locations/us/ny/new_york_city のような固有の URI を持つ。このリソースを扱うクライアントは標準のHTTPメソッドを使う。例えば、

HTTP GET を使ってリソースのコピーをダウンロードする。
更新したコピーを HTTP PUT によりアップロードする。
HTTP DELETE によりそのリソースの全ての表現を削除する。

なお、それぞれのリソースが固有の URI を持っているので、キャッシュ、コピー、ブックマークすることが簡単にできることに注意してほしい。HTTP POST は一般に副作用のあるアクションに対して使われる。たとえば購入の注文を行ったり、コレクションに情報を追加したりするために使われる。

一例として、次のようなXML形式のユーザーのデータを扱うことを考える。

<user>
 <name>Jane User</name>
 <gender>female</gender>
 <location href="http://www.example.org/locations/us/ny/new_york_city">
  New York City, NY, US
 </location>
</user>

ユーザーの location (住所) を更新するためには、RESTクライアントはまず上記のXMLデータを HTTP GET によりダウンロードする。それからXMLデータの location を変更して、HTTP PUT によりアップロードする。

HTTP のメソッドが、リソースを発見するための標準的なメソッドをすべて提供してはいないことに注意してほしい。

RPCの上記の例における list*() や find*() に相当する、HTTP LIST や FIND のようなメソッドは HTTP では規定していない。

REST は、その代わりに、扱う対象とするコレクションや検索結果の集合を、別の型の「リソース」として扱うことで問題に対処する。アプリケーション設計者は、リソースの検索や一覧取得のために状況に応じてその URI やURIパターンを知っておく必要がある。

いくつかの例を示す。

http://www.example.org/locations/us/ny/ という URI への HTTP GET リクエストは、ニューヨーク各地の情報をもつXMLファイルへのリンクの一覧を返す。
http://www.example.org/users?surname=Michaels という URI への HTTP GET リクエストは、"Michaels" の姓をもつ全てのユーザーへのリンクの一覧を返す。

REST は、このようなアクションをどのように行うかについてのいくつかの手がかりを提供する。この手がかりは、REST の原則を構成する制約の一つ「アプリケーション状態のエンジンとしてのハイパーメディア」から得られる。この制約から導かれる実現手段の一つは、パラメタつきのリクエストに対しては、フォーム言語 (HTMLフォームなど) を使うことである。

A9.com の OpenSearch イニシアチブは、REST を使った検索の標準化作業を行っている。具体的には、RDF、XTM、Atom、RSS (方言を含む)、リンクを扱うための XLink と組み合わせた簡単な構造の XML (Plain Old XML; POX) を含む一般的なフォーマットをRESTシステムで使うことにより、情報を発見するための規格の策定である。

[編集] 公開されている実装

REST はかなり広い意味で定義されているので、広義に捉えると非常に多くの数の RESTful アプリケーション (HTTP GETリクエストによりアクセス可能なすべてのもの) がウェブ上に存在すると考えることができる。REST を、一般的なWebサービスやRPCスタイルとは異なるものとして狭義に捉えても、REST は公開されたウェブ上の随所に見つけることができる。

ブログ圏――ウェブログの世界――の大部分はRESTベースである。ブログでは、他のリソースへのリンクの一覧を含むXMLファイルを (RSS 2.0、RSS 1.0、Atomフォーマットで) ダウンロードする。
Amazon.com はデベロッパーインターフェイスを、RESTバージョンとSOAPバージョンの両方で提供している (RESTバージョンがトラフィックの大部分を占めている) 。
eBay は REST デベロッパーインターフェイスを提供している。
カナダ政府の "Seniors Canad On-line"プロジェクトはRESTインターフェイスを提供している(説明)。
Bloglines は REST デベロッパーインターフェイスを提供している。
Yahoo! は REST デベロッパーインターフェイスを提供している。
Openomy は REST ベースのオンラインファイルストレージシステムである。
Ruby on Rails におけるURLルーティングでは、MVC デザインパターンを使うことにより、RESTful アプリケーション設計を支援する。
Zope のオブジェクト出版システム。

同様のものが他にも多く提供されているとみられる。

なお、上記の多くのものは完全に RESTful というわけではない。つまり、それらは REST の全てのアーキテクチャの制約に従っているわけではない。とはいえ、どれも REST から刺激を受けたものであり、RESTのほとんどのアーキテクチャの制約の重要性を認識している。特に統一的なインターフェイスの制約についてはそうである。これらのサービスは「偶然によるRESTful」と呼ばれることがある。