RESTful Webサービス

RESTful Webサービス

Ruby on Railsを使ってWebアプリケーションを作りたいと思ったのだけど、Ruby on Railsの1.2からRESTfulなアプリケーションの作成を支援するツールになったらしいので、読んでみた。

RESTfulアーキテクチャやリソース指向アーキテクチャの概念を学ぶという観点からすると、例を見せながら説明するという形なので、ソースコードが得意な方でないとちょっと読みにくい（少なくとも私は読みにくかった）。

以下、メモ。なお、以下のメモは本の内容どおりではなく私の理解を書いたものなので鵜呑みにしてはいけない。

RESTとRESTfulアーキテクチャ

REST（Representational State Transfer）は、Roy Fieldingが博士論文で提唱した分散ソフトウェアの一連の設計条件のこと。なのでWebアプリケーションやWebサービスのみに適用される設計条件ではない。

RESTfulアーキテクチャとは、RESTを満たしているアーキテクチャのこと。「RESTアーキテクチャ」というアーキテクチャはない（すなわち、RESTを満たすアーキテクチャが複数あり得る）。

静的なWebサイトはすべてRESTfulアーキテクチャと見なすことができる。

RESTfulアーキテクチャとリソース指向アーキテクチャ

リソース指向アーキテクチャ（ROA）は、本書で提案されたWebアプリケーションやWebサービスのアーキテクチャ。ROAはRESTfulである。この話のまとめは第4章に書いてある。

リソースとは、コンピュータ上に格納することができ、一連のビットで表せるものである。たとえば、ドキュメント、データベースの行、またはアルゴリズムを実行した結果などである。

リソースは少なくとも一つのURIを持たなければならない。一つのURIも持たないものはリソースではない。複数のURIが同一のリソースを指し示すこともあり得るが、出来る限り同一のリソースを指し示すURIは少ない方が良い。

ROAは４つの特徴を持つ。アドレス可能性とステートレス性、接続性、そして、統一インターフェースである。

アドレス可能性：アプリケーションがそのデータセットの重要な部分をリソースとして公開する場合、そのアプリケーションはアドレス可能である。
ステートレス性：すべてのHTTPリクエストが完全に分離していること。クライアントが送信するHTTPリクエストには、サーバーがそのリクエストを処理するためのすべての情報が含まれている。
接続性：あるリソースから他のリソースへのリンクを持つこと
統一インターフェース：HTTPの6つの基本メソッドGET, PUT, DELETE, POST, HEAD, OPTIONSが定義どおりに使われていること。

ステートレス性についての補足

RESTfulなアプリケーションでは、リソースの現在の状態のみをサーバー側で保持し、クライアント側の状態（アプリケーション状態）を保持しない。アプリケーション状態はクライアント側が保持する。たとえば、検索エンジンを使用する際、現在のクエリと現在のページはアプリケーション状態である。なぜならば、これは複数のクライアントが同じキーワードを検索していたとしても、あるクライアントは1ページ目を受け取っており、別のクライアントは2ページ目を受け取っていたりするとおり、クライアントごとに異なるためである。一方で、リソース状態はすべてのクライアントで同じである。

統一インターフェースについての補足：安全性とべき等性

安全性とは、リクエストを発行してもサーバーやリソースの状態変更を発生しないこと。GET・HEADリクエストはリソースの読み取りリクエストであるため、これらのリクエストは安全でなければならない。

べき等性とは、リクエストを1回発行したときにはサーバーやリソースの状態変更が発生するが、同じリクエストをさらに発行しても、2回目以降のリクエストによるリソースの状態は1回目のリクエストによるリソース状態と全く同じであること。GET、HEAD、PUT、DELETEリクエストはべき等でなければならない。

統一インターフェースについての補足：POSTリクエストの役割

統一インターフェースにおけるPOSTリクエストは、主に従属リソースを作成するために使用される、通称POST(a)の使い方
をされ、フォームの送信結果などのデータブロックをデータ処理プロセスに提供するPOST、通称POST(p)の使い方はしない。

リソース指向アーキテクチャ、RPCスタイルアーキテクチャ、REST-RPCハイブリッドアーキテクチャ

メソッド情報とスコープ情報の取り扱いの違いから、Webサービスを3つに区分けすることができる。

メソッド情報とは、クライアントからサーバーに与えられるデータの操作に関する情報のことである。スコープ情報とは、クライアントからサーバーに与えられるどれが操作対象のデータであるかという情報である。

	リソース指向アーキテクチャ	RPCスタイルアーキテクチャ	REST-RPCハイブリッドアーキテクチャ
メソッド情報の扱い	HTTPメソッドとしてのみ与えられる	エンベロープに含まれる	一部のメソッドはHTTPメソッドとして与えられる。他はエンベロープに含まれる
スコープ情報の扱い	URIとして与えられる	エンベロープに含まれる	メソッドによってはURIに含まれる
サービスが提供するURIの数	リソースの数だけ	1つ〜数個	GETやHEADの場合はリソース分、その他は数個
代表的なサービス	静的Webサイト、Atom Publishing Protocol、Amazon S3	XML-RPCを使用するすべてのサービス、ほぼすべてのSOAPサービス	del.icio.us API、「REST」Flickr Web API、その他多くのRESTfulとされているWebサービス

Ruby on Railsでリソース指向アーキテクチャのWebアプリケーションを作成する際のメモ

第7章はRuby on Railsでリソース指向アーキテクチャのWebアプリケーションを作成する例。また、12章には、6章で解説した汎用的な設計手順のRoR特化版が載っている。

重要な点は、Ruby on RailsにおけるModelがリソースではない。コントローラーがリソースに対応する。Usersコントローラーがあり、ユーザーのデータベースIDを52とした場合のコントローラーのメソッドとHTTPアクションの対応は以下の表（本書 p. 181 表7-1）のとおりになる。

操作	HTTPアクション	コントローラーのメソッド
ユーザーの一覧表示	GET /users	UsersController#index
ユーザーを作成	POST /users	UsersController#create
ユーザーの表示	GET /users/52	UsersController#show
ユーザーの修正	PUT /users/52	UsersController#update
ユーザーの削除	DELETE /users/52	UsersController#destroy

一覧表示とユーザの表示はGETリクエストで同じだけれども、URIによって呼び出されるメソッドが異なることに注意。

12章 p.363のRoRによるROAの設計手順

データセットを特定する

データセットをコントローラーに割り当てる。各コントローラーに対して以下を実行する

このコントローラーはリストまたはファクトリリソースを提供するか（上の表でいう /users）

このコントローラーは一連のオブジェクトリソースを提供するか（上の表でいう /users/52）

このコントローラーは作成または編集用のフォームリソースを提供するか

リストおよびオブジェクトリソースに対して、

Rails標準と異なる場合、クライアントから受け取る表現（1つ以上）を設計する

クライアントに提供する表現（1つ以上）を設計する

このリソースを既存のリソースに接続する

イベントの標準的な流れを検討する：何が起きるはずか？

エラー状況に対して検討する：どのようなエラーが発生し得るか。

発声練習