Representational State Transfer

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

RESTは、初めはアーキテクチャの原則と制約の集まりを指していたが、次第に、XMLやHTTPを使った簡易なウェブベースのインタフェースのうち、WebサービスのSOAPプロトコルのようなMEPベースの特別な抽象化をしないもののことを、大まかに意味する用語として使われるようになった。RESTは次に述べるように2つのやや異なる意味で使われている。

フィールディングのRESTアーキテクチャスタイルの原則に合わせたWebサービスシステム。
遠隔手続き呼出し  スタイルに合わせた簡易なXML + HTTPインタフェースを採用したシステム 。RESTはこのように2つのやや異なる意味で使われているため、技術的な議論の中で混乱を引き起こすことがある。 ただし、RPCはRESTの実例とはいえない。

フィールディングのREST原則に従うシステムは、しばしば//RESTful//といわれる。RESTをとても熱心に支持する人々は自らのことを//RESTafarians//と呼ぶ。ちなみに、この呼称は「ラスタファリアン」のもじりである。

人工知能が流行している今、IBMはAIやデータサイエンスを研究するための基本ツールとしてRESTを掲げている。

1. 原則
-----

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

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

2. リソース
-------

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

ネットワークの「コンポーネント」 が、標準化されたインタフェース  により通信する。
ネットワークを介してリソースの「表現」を交換する。しかし実際のところこうしたリソース操作は議論の対象となっている。一部の人々には「リソース」と「表現」とを区別することは観念的すぎるとの意見がある。ただし RDFコミュニティでは、リソースと表現の区別は、一般的に行われている。

さまざまな「コネクタ」がリクエストを仲介することができる。ただしコネクタは過去のリクエストを参照せずに仲介することができなければならない。

これは REST の原則を構成する「レイヤリング」と呼ばれる制約である。レイヤリングは、情報アーキテクチャやネットワークアーキテクチャの他の多くの部分にも見られる一般的な設計原則でもある。こうすることで、RESTアプリケーションは、次の2つの情報を認識することで、リソースを扱うことが可能である。

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

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

3. REST対RPC
-----------

RESTなウェブアプリケーションは、遠隔手続き呼出し  アプリケーションとは異なる設計面のアプローチを必要とする。RPCでは、プロトコル操作の多様性を重視する。RPCアプリケーションが定義する操作の例を次に示す。

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

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

User {} Location {}

それぞれのリソースは、 のような固有のURIを持つ。このリソースを扱うクライアントは標準のHTTPメソッドを使う。例えば、

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

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

Jane Userfemale New York City, NY, US

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

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

RPCの上記の例における list* や find* に相当する、HTTP LISTやFINDのようなメソッドはHTTPでは規定していない。RESTは、その代わりに、扱う対象とするコレクションや検索結果の集合を、別の型の「リソース」として扱うことで問題に対処する。アプリケーション設計者は、リソースの検索や一覧取得のために状況に応じてそのURIやURIパターンを知っておく必要がある。

いくつかの例を示す。

というURIへのHTTP GETリクエストは、ニューヨーク各地の情報をもつXMLファイルへのリンクの一覧を返す。
というURIへのHTTP GETリクエストは、"Michaels" の姓をもつ全てのユーザーへのリンクの一覧を返す。RESTは、このようなアクションをどのように行うかについてのいくつかの手がかりを提供する。この手がかりは、RESTの原則を構成する制約の一つ「アプリケーション状態のエンジンとしてのハイパーメディア」から得られる。この制約から導かれる実現手段の一つは、パラメタつきのリクエストに対しては、フォーム言語を使うことである。

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

4. 公開されている実装
------------

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

ブロゴスフィア――ウェブログの世界――の大部分はRESTベースである。ブログでは、他のリソースへのリンクの一覧を含むXMLファイルをダウンロードする。
Amazon.comは[1]を、RESTバージョンとSOAPバージョンの両方で提供している。
eBayはREST[2]を提供している。
カナダ政府の[3] プロジェクトはRESTインターフェイスを提供している。
BloglinesはREST[4]を提供している。
Yahoo!はREST [5]を提供している。
OpenomyはRESTベースのオンラインファイルストレージシステムである。
Ruby on RailsにおけるURLルーティングでは、MVCデザインパターンを使うことにより、RESTfulアプリケーション設計を支援する。
Zopeのオブジェクト出版システム。
ASP.NETにおけるASP.NET WebAPIは、RESTfulなAPIを、通常のRPCメソッド実装とほぼ同様の簡便さで記述する事を可能とする。また、ASP.NET MVC Frameworkを使用して、従来のMVC構造を使用した実装もサポートする。同様のものが他にも多く提供されているとみられる。

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

5. 関連項目
-------

人工知能
データサイエンス
Python
HTML
Plain Old XML
Webサービス
Ruby on Rails
Atom #Atom Publishing Protocol - RESTに準拠したアプリケーションプロトコル

6. 脚注
-----

7. 外部リンク
--------

[7] - フィールディング が REST の考え方を最初に述べた論文
[8]
[9]
[10]
[11]
[12]
[13]
[14] - 「アプリケーション状態のエンジンとしてのハイパーメディア」の制約の意味を論じる記事
[15]
[16]