REST とは リソースの状態を表す「何か」を転送するということを表した、Webアーキテクチャスタイルです。REST はアーキテクチャではなく、アーキテクチャのスタイルであり、実際に REST スタイルのアーキテクチャとして、ROA（リソース指向アーキテクチャ）などがあります。
本書は、この REST と ROA に関して解説されたもので、RESTful なシステム（REST スタイルに則ったシステム）の設計方針、ROA の考え方などが解説されています。
Web アプリケーション開発をこれまでしてきた中で、RESTful や ROA な考えでシステムを設計したことがない人には、新しい発見があり、とてもわくわくして読むことが出来ます。
本書は、特に、Web アプリケーションの設計者、アーキテクトの方が読むと良いと思います。最近話題の REST の詳細を理解したい人、RESTful システムを構築したい人、ROA の考え方を取り入れたい人に本書はお勧めです。
オライリーっぽいちょっとお堅い文章ですが、楽しく読めると思います。『WEB+DB PRESS vol.42』の現場で使える REST の記事を読んで、REST とは何か？ ROA とは何か？の概要を抑えてから読むと、理解が早いと思います。
お勧めです。
参考
おぼえがき
RESTとは
REST とは、リソースの状態を表した「何か」を転送するということを表した、Web アーキテクチャスタイルです。REST は Representational State Transfer の略で「表現可能な状態」を「転送する」という意味を表しています。
たとえば、商品在庫一覧.htmlというファイルがあるとします。これは商品という「リソース」が在庫であるという「状態」を、HTML形式で「表現」していると見なせます。このHTMLファイルをサーバからブラウザに「転送」するから、「表現可能な状態」を「転送」している、つまり Representational State Transfer なのです。
REST はアーキテクチャのスタイルであり、REST というアーキテクチャがあるわけではありません。REST スタイルのアーキテクチャの一つに、ROA（Resource Oriented Architecture:リソース指向アーキテクチャ）というものがあります。
ROA（リソース指向アーキテクチャ）とは
ROA とは、リソースを主体として考えていくアーキテクチャのことです。
リソースとは
ROA におけるリソースとは、参照（認識）するに値する重要性を持つものとして定義されています。
「それに対してハイパーテキストリンクを作成する、それに対して意見または反論する、その表現を取得またはキャッシュする、あるいはその他の操作を実行する」ことがある場合は、それをリソースにすべきである。
URI
リソースがリソースであるための条件として、リソースは少なくとも一つの URI を持っていることがあげられます。
- Tips
URL と URI の違いですが、現在では同じ意味で使われているようです。URL（Uniform Resource Locator）は、インターネット上の情報資源を指し示すもので、ホスト名、ポート名、フォルダ名、ファイル名などが含まれています。しかし、同じ情報資源であっても、ホスト名が変更になると URL は変化してしまうという問題があったため、ホスト名とか場所とか変わっても同じものを指し示すものが必要ということで URN（Uniform Resource Name）というものが定義されました。これら URL と URN をあわせたものが URI と呼ばれるものです。なお、URI（Uniform Resource Identifier）もインターネット上の情報資源を指し示すもので、包括的な概念として定義されています。URI の具体的な仕様が URL に当たります。
URI は構造的でなければならない。それらの構造は予測可能な方法で区別されなければならない。<中略> これは REST な絶対的なルールではない。厳密には、URI が構造的である、あるいは予測可能である必要はないが、筆者はそうあるべきだと思っている。
ROA の特徴
ROA には次の特徴があります。
アドレス可能性
公開されているリソースは、URI を通じてアクセスすることができます。このとき、この URI を本に掲載することが出来るのであればそれはアドレス可能であるといえます。
たとえば Ajax アプリケーションやGmailなどは、同一の URL （ブラウザのアドレス）から変化せずにアプリケーションの各機能を実行することが出来ます。これらは、アドレス可能ではない例になります。
HTTPがアドレス可能ではなかったら、あるいはGoogle検索がアドレス可能なWebアプリケーションではなかったら、そのURIを本に掲載することは出来ない。「google.com への Web 接続を開き、検索ボックスに「jellyfish」と入力し、[Google 検索]ボタンをクリックする」と指示しなければならないだろう。
ステートレス性
すべての HTTP リクエストが完全に分離していることです。サーバの処理が以前の HTTP リクエストに依存せずに実行できるような場合、ステートレス性が保たれているといえます。
ステートレス性は、サーバーが取り得る状態もリソースであり、独自のURIが割り当てられるべきであることを意味する。
これはつまり、URI によってサーバの状態が判断できるようにするべきだということです。特定のリクエストを送るために、あらかじめ別のリクエストを送って、サーバ側の状態を変更しておく必要がないような設計でなければならないということになります。
ステート（状態）には二種類あり、一つはクライアント側で維持されるアプリケーション状態と呼ばれる状態で、もう一つは、サーバ上で維持されるリソース状態です。
アプリケーション状態とは、アプリケーションのユーザが今どのような状況にいるのか（ログインしているのか？検索結果の3ページ目を表示しているのか？）というものを表したものです。リソース状態とは、各ユーザがどのような状況にいても変わらない情報のことで、これらはサーバ側に格納します。
サーバは、クライアントからアプリケーション状態を受け取ると、受け取ったリクエスト情報を元にアプリケーションの状態を復帰します。以前のリクエスト状態を覚えておくというようなことはしません。
ただし、クライアントから受け取ったリクエストだけを信頼すると嘘の情報を渡される可能性があります。そのため、セッションの仕組みを使い、（仕方なく）サーバ側にユーザ情報を保持しておくという実装が現在では行われています。
繰り返しますが、アプリケーションに関する状態情報はクライアント側で保持し、サーバにはリソースの情報しか保持しないというのがステートレス性の特徴になります。
HTTPセッションの現在の状態はリソース状態としてサーバーに格納されないが、アプリケーション状態としてクライアントによって追跡され、クライアントがWebでたどるパスから作成される。サーバーは、ハイパーメディア（ハイパーテキスト表現内のリンクとフォーム）を提供することにより、クライアントのパスを導く。
接続性
ステートレス性のところの最後の引用に記述されている、「サーバーは、ハイパーメディア（ハイパーテキスト表現内のリンクとフォーム）を提供することにより、クライアントのパスを導く。」これが、接続性というものです。
ユーザがすべての URI を知っている必要はなく、この接続性（ハイパーリンク）によって、次のリソースや次のサーバ状態に移行できることが重要です。
そう、次はこっちの状態かこっちの常態化どちらかがありますよというサーバの提案がアプリケーションを構成しているので、リンクっていうのはすごい重要なんです。
ただ、現状の Web API とか Web サービスではなかなかリンクは出てこないですね。XML を返してくれても、その XML の中に URL が入っていないので、接続されているとは言いがたいサービスが多いんですが、本当は HTML でみんながすでにやっていること、Web UI でやっていることなので、それをそのまま API でもやると、実はさらに良いシステムを作っていけるんじゃないのかなと思います。
統一インターフェース
Web サービスを使う場合、起動するメソッド名の情報をリクエストに含めたりします。しかしこの方法では、利用する Web サービスごとに呼び出すメソッドが違ってしまい、Web 全体を考えた際にリソースに対する処理インターフェースが統一できません。（もちろん、命名規約で縛ることも可能ですが。。。）
そこで、ROA では、Web 全体でリソースに対する操作を行うインターフェースを統一しようというスタイルが提案されました。
ここで提案された統一インターフェースが HTTP のメソッド（GET、PUT、POST、DELETE）になります。
- GET
- リソースを取得するメソッドです。GET メソッドはサーバの状態を変更しない用途で使用します。（厳密には副作用があってもよいとされています。たとえば、GET アクセスごとにインクリメントされるカウンタなどは、GET による副作用がありますが、クライアントに責任はなく、甚大な被害があるわけではないので問題ないとされています。）
- PUT
- 主に、リソースの状態を変更する際に使うメソッドです。リソースの新規作成にも使われることがあります。PUTはべき等性を持ちます。
- Information
- べき等性とは、何度同じリクエストを繰り返し実行しても同じ結果であることを意味する数学用語です。
- POST
- リソースの新規作成の際に使うメソッドです。多くの Web アプリケーションでは、GET と POSTのみが有効なメソッドとして処理されています。GETはリソースの取得、POSTは新規作成、更新、削除など汎用的な処理として使われることが多くあります。ROA 的には POST はリソースの新規作成でのみ使うことがよいとされています。
- Information
- とはいえ、現在のHTMLフォームでは、GET と POST しかサポートされていないため、このような現状は仕方ないといえるかと思います。POST に新規作成以外の意味を持たせて使うことを、オーバーロードPOSTと呼びます。
- PUT でリソースを新規作成する場合
- クライアントが指定した URI のリソースが新規作成される
- POST でリソースを新規作成する場合
- クライアントが指定する URI はリソースを新規作成するリソースの URI。新規作成されたリソースの URI はサーバが決定する
- DELETE
- リソースの削除を行う際に使うメソッドです。DELETEもべき等性を持ちます。
ここからは後で書く