REST 入門(1 Web アプリケーションのアーキテクチャ)
初出: 技術評論社刊『WEB+DB PRESS』Vol.32
はじめに
先進的な Web 開発者の間で、REST (Representational State Transfer) という言葉が注目を集めています。REST はApache 創始者のひとりであるロイ・フィールディングさんが、彼の博士論文で提唱したネットワーク分散システム、特に WWW のアーキテクチャスタイルです。
アーキテクチャスタイル(Architectural style) は複数のアーキテクチャに共通する性質、様式、作法あるいは流儀を指す言葉です。たとえば MVC (Model View Controler) はアーキテクチャスタイルの一種です。REST は数あるアーキテクチャスタイルの中でも特にネットワークシステムのアーキテクチャスタイルになります。
本稿では Web アプリケーションの開発にかかわる方を対象として、REST アーキテクチャスタイルの意義と意味を解説します。
Web アプリケーションのアーキテクチャ
REST は WWW のアーキテクチャスタイルです。REST を理解するには、WWW のアーキテクチャでどのように REST が実現されているかを見ていくのがわかりやすいでしょう。
POST と GET の使いわけ
Web アプリケーションを開発するときに必ず出てくるのが form タグです。form タグ経由でブラウザから入力された情報を使うと、動的な Web サイトを構築することができます。form タグには method という属性があり、”get” あるいは “post” という値を指定します。これはフォームに入力した情報をaction 属性で指定した URI に送信する際に、 HTTP の GET メソッドを使うか POST メソッドを使うかを指定する属性です。
ところでみなさんは、この GET と POST をどのように使いわけていますか? たとえばオンラインショップで商品を発注するときは GET と POST のどちらを使いますか。あるいは商品検索は GET でしょうか、POST でしょうか。
普段私たちが何気なく使っているこれらの属性には明確な使いわけの基準があります。その使いわけの基準はその操作に副作用があるかどうか、になります。その操作によって、サーバ側のリソースの状態が変化するときは POST を、状態が変化しないときは GET を使います。商品を発注するということは受注DB内に新しいレコードを追加することになりますから、この場合は POST を使いま
す。逆に商品を検索するというのは何回実行しても商品DBの状態に影響を与えません。従ってこの場合は GET を使います。
リソースと統一インターフェース
上記でリソースという言葉が出てきました。リソースは名前を持った情報であり、REST を構成する重要な概念です。リソースの具体例を以下に挙げます。
- 東京の天気予報
- 商品の検索結果
- 2006年4月1日のスケジュール
リソースが名前を持つとはどういうことでしょうか。この場合の「名前」はそのリソースを指し示す識別子のことです。Web の識別子といえば URI ですね。つまり、リソースとは Web 上で「これ」とか「あれ」というように指し示すことのできるもの、ということになります。
URI で指し示されるリソースは、時間や条件によって内容が変化する可能性があります。たとえば、今日見る天気予報と明日見る天気予報では、含まれる内容は異なります。しかし、両者とも天気予報であることにはかわりありません。
今、リソースの内容と書きましたが、その内容は取得する時点でのリソースの状態で決まります。天気予報というリソースは、時間の経過と共に状態が変化していくと考えるとわかりやすいと思います。各時点での取得できる具体的な内容をリソースの表現 (Representational State) と呼びます。リソースの表現をサーバからクライアントに転送 (Transfer) するのが Representational State Transfer すなわち REST です。
この URI で指し示されるリソースに GET や POST やその他の HTTP メソッドを適用するのが Web のアーキテクチャスタイルの最大の特徴になります。全ての Web システムで URI と HTTP という同じインターフェースを利用するこのスタイルのことを統一インターフェースと呼びます。
階層化システム
統一インターフェースの利点の一つにシステム全体が階層化しやすいことが挙げられます。たとえば Web アプリケーションでは、Web サーバとクライアント(ブラウザ)の間にロードバランサやプロクシを設置して負荷分散を行います。クライアントからしてみると、サーバもプロクシも同じインターフェースで接続できるので、接続先が Web サーバからプロクシに代わったことを意識しないで済みます。これは Web サーバやプロクシという各コンポーネント間のインターフェースが HTTP で統一されているからです。この階層化システムも REST を構成するスタイルの一つです。
ステートレスサーバ
REST アーキテクチャスタイルを構成する重要なスタイルのひとつにステートレスサーバがあります。ここでいうステートレスとは、クライアントの状態をサーバで管理しないことを意味します。
サーバが状態を持たないことの利点はサーバ側の実装が簡略化されるところです。サーバの実装では、クライアントからのリクエストに応えた後すぐに、計算機リソースを解放できます。
サーバをステートレスに実装するためには、クライアントからのリクエストメッセージに、そのリクエストを処理するために必要な全ての情報が含まれていなければなりません。たとえば、クライアントがサーバに接続するときに、まず認証とセッション開始処理を行い、そこで得られるセッション ID を使って2番目以降の処理を行う、という実装はステートレスではありません。これをステートレスにするためには、全てのリクエストメッセージに認証に必要な情報を含める必要があります。このように一回一回のリクエストメッセージがそれ自身で完結していることを自己記述的メッセージ(self describing message)と呼びます。
しかし、現実の Web アプリケーション実装ではそうでないものも多々あります。HTTP をステートフルにする代表格はクッキーを使ったセッション管理です。REST アーキテクチャスタイルの視点からみると、クッキーを使ったセッション管理は間違った HTTP の拡張、ということになります。
クッキーのように REST 的に見ると間違っているものが現実世界にはいくつか存在します。でも REST 的に間違っているからといって、クッキーを使ったフォーム認証をやめるわけにはいかないというのもまた現実です。しかし、やめられないから REST を無視していい、となるのではなく、REST アーキテクチャスタイルを知った上で必要悪として最小限のクッキーを使うべきである、と筆者は考えています。
(次回に続きます)