読者です 読者をやめる 読者になる 読者になる

Programming log - Shindo200

イベント参加記録とプログラミング系の雑記

少しずつですが『Web を支える技術』を読んでいます

REST って思想がいろいろとあって、議論が止まなくて、怖いものというイメージを持っている人がいると思います。僕がそうでした。RESTについて勉強していた頃に、自分用のメモとして書いたレポートを掲載します。この記事で怖いというイメージを少しでも消すことができれば幸いです。


【スタートアップ! REST】
まずは Wikipedia を眺めてみてください。わからなくても眺めるだけで良いです。
http://ja.wikipedia.org/wiki/REST
RESTの入門記事を書かれている、こんなサイトもあります。
http://yohei-y.blogspot.jp/2005/04/rest_23.html
手元に「Web+DB Press vol.32」や「Web を支える技術」がある方は眺めてみてください。どの資料を見ても、最初のほうに必ず出てくるキーワードがあることに気づきました。そのキーワードは「リソース」です。「リソース」とは何だろう。


【リソースとは】
リソースとは「Web上に存在する、名前を持ったありとあらゆる情報」のことです。しかし、Web上に存在する情報とは何だろう。具体例として下記の情報になります。
Yahoo!天気の東京の天気予報 http://weather.yahoo.co.jp/weather/jp/13/4410.html
Amazon の「Web を支える技術」のページ http://www.amazon.co.jp/exec/obidos/ASIN/4774142042/
・ブログの記事(今見ているこの記事)
これらの情報は全てWeb上に存在します。Web上に存在する情報を見るためには、名前を使って他の情報と区別できなければいけません。この区別するための名前というのが URI です。Web上にある無数の情報に URI という一意の名前を付けたもの、これがリソースです。


【リソースにアクセスする】
リソースのURIをブラウザに打ち込むと、リソースにアクセスできます。試しにブラウザにYahoo!天気の東京の天気予報を打ち込んでみます。すると、下記のHTTPリクエストがWebサーバに送られます。
f:id:Shindo_Masaya:20130208175944j:plain
HTTPのGETメソッドが発行されています。このリクエストを受け取ったWebサーバはステータス200(OK)のレスポンスを返します。
リソースにGETメソッドを送ることで、そのリソースをGET(取得)することができました。


【リソースのアドレス可能性】
リソースにはURIが付けられています。URI にはそのリソースが置かれている「サーバ」「ディレクトリ構造」「ファイル名」と「リソースを取得するためのプロトコル」が書かれています。Yahoo!天気を例に使うと、
サーバ: weather.yahoo.co.jp
ディレクトリ構造: /weather/jp/13
ファイル名: 4410.html
プロトコル: HTTP
です。もしも URI がなかったら、自然語で書かれた言葉からサーバなどの情報をプログラムが解析して、ファイルをダウンロードしなければいけません。URI は決められた構造を持っているから、プログラムが簡単に処理できます。URI を使ってリソースを簡単に指し示せる性質のことを「アドレス可能性」と呼びます。リソースは名前が付けれていると、プログラムが処理しやすくなります。


【RESTとは】
REST とはWebアプリケーションはこういう構造にしたほうが良いという思想の集まり(アーキテクチャパターン)です。
RESTの思想の1つ目は「すべてのリソースは一意な名前を持つこと」。これは先ほど説明した URI のことです。2つ目は「すべてのリソースはよく知られた操作で処理できること」。これはリソースがHTTPメソッドの GET(取得), POST(作成), PUT(更新), DELETE(削除) で処理できることです。


【RESTで重要な4つのHTTPメソッド
HTTPメソッドにはクライアントが行いたい処理をサーバに伝えるという役割があります。
全部で8つのメソッドがあるのですが、RESTで重要なのは、そのうちの4つのメソッドです。

1. GET
GETメソッドは指定したリソースを取得します。Webページの取得、画像の取得など、リソースを取得するときに使うメソッドです。

2. POST
POSTメソッドはリソースを作成します。

3. PUT
PUT メソッドはリソースの内容を更新するときに使います。また、PUTメソッドでもPOSTメソッドのようにリソースを作成することができます。しかし、リソースの新規作成はPUTメソッドでやらないほうが良いです。RFC2616 9.6項に「PUTメソッドで作成されたリソースの URI は、クライアントが指定した URI とする。サーバで URI を決めるべきではない」という規則があります。そして、RESTには「サーバの URI がどのように組み立てられているか、クライアントは知らなくて良いようにする」という思想があります。PUTメソッド でリソースを作成する場合、URI はクライアントが決めることになるので、クライアントがサーバの URI の管理方法を知らなければいけません。POSTメソッドであれば、作成されるリソースの URI をクライアントが意識する必要がなくなります。リソースを作成するときはPOSTメソッドを使ったほうが良いです。

4. DELETE
DELETE メソッドはリソースを削除します。


【ステートレス/ステートフル】
RESTにはもう一つ大事な思想があります。それは「Webサーバとのやりとりがステートレスであること」です。Webアプリケーションに関わらず、やりとりにはステートレスとステートフルがあります。ステートフルなやりとりでは、アプリケーションにログインしてからの一連の操作をサーバが記憶します。サーバがクライアントの状態を記憶しているので、クライアントがサーバに送る情報は少なくてすみます。しかし、サーバに負担がかかってしまいます。
この問題を解決するのがステートレスなやりとりです。ステートレスなやりとりでは、クライアントの情報をサーバが保持しません。ログインしてからの一連の操作をクライアントがサーバに毎回伝えます。サーバは来たリクエストの内容をそのまま解釈して処理すればよくなるので、システムはシンプルはなります。


【まとめ】
僕がREST についてレポートを書いてみて、大事だと感じたことをまとめます。
・リソースとは、Web上のありとあらゆる情報のこと。
・リソースは一意な名前(URI)でアクセスできる。
・HTTPメソッドは GET, POST, PUT, DELETE の4つでシンプルに処理する。
・HTTPメソッドはそれぞれの役割を知って、正しく使い分ける。
・ステートレスなやりとりができるように実装する。
・シンプルな実装を心がける。


【参考】
山本陽平 (2005) REST 入門 http://yohei-y.blogspot.jp/2005/04/rest_23.html
山本陽平 (2006) Web+DB Press vol.32 - REST アーキテクチャスタイル入門
山本陽平 (2010) Web を支える技術 HTTP,URL,HTML,そしてREST
RFC2616 http://www.ietf.org/rfc/rfc2616.txt
橋本英彦 RFC2616の日本語訳 http://www.studyinghttp.net/cgi-bin/rfc.cgi?2616