アーキテクチャスタイル「REST」とは何か

RESTとは

   続いて、RESTという考え方について見ていきましょう。RESTという言葉は、例えば「Amazonの商品情報取得APIであるECS（注2）では、SOAPとRESTのインターフェイスが用意されている」といった形で耳にした方も多いのではないでしょうか。この言い方を聞くと、RESTもSOAPと同じようなWebAPIのための仕様であるような印象を受けますが、最初に「考え方」と述べたように、実際には仕様ではなく、Web APIの仕様を決める上でのアーキテクチャスタイル、つまり基本的な考え方ということができます。

---

   ただしここでまず最初に覚えておいてほしいことは、一般的にRESTという言葉は、RESTという言葉が誕生したときの本来の意味で使われる場合と、その後その解釈を拡大して、もっと広い意味で使われるようになったものの2通りがあるということです。例えば前述のAmazonのECSがRESTで提供されている、というときのRESTは、後者の広い意味で使われている方を意味しています。どうしてそうなるのかはこれから説明していきますが、まずは本来の意味でのRESTについて解説していくことにします。

   もともとRESTとは、Representational State Transferの略で、HTTPのプロトコルの策定にも関わったRoy Fielding氏の博士論文で初めて使われた言葉です。RESTは「リソース」を扱うための考え方であり、「リソース」とは、ブログの記事であったり、アップロードした写真であったり、もしくはWebページ全体のコンテンツであったりといった、ひとかたまりの情報を指します。

   RESTの考え方では、リソースはそれぞれ固有のURIを持っています。そしてそのURIにアクセスすることで、それぞれのリソースを操作することになります。その際の操作はHTTPのメソッドを「正しく」使うことで行います。つまりHTTPの4つメソッド、すなわち「GET」「POST」「PUT」「DELETE」で何を行うかを伝えるというわけです（表4）。

メソッド	役割
GET	リソースの取得。GETでのアクセスはリソースの内容に影響を与えない。
POST	リソースの新規作成
PUT	既存のリソースのアップデート
DELETE	リソースの削除

   これらの4つのメソッドは、HTTPの仕様としてもともと存在していたものですが、一般的なWebへのアクセスではGETとPOSTくらいしか使われていません。しかしRESTの考え方では、それぞれのメソッドに意味を持たせる、というよりも本来の意味で利用することで、URIとメソッドの組み合わせて、そのリソースに対して何をしたいのか、を指定できるようにしようと提唱しています。

   それに対してAmazonのECSなどが用いている広義のRESTの考え方は、単にHTTPとXMLを利用してリソースの操作を行うという単純なくくりになっています。例えばAmazonのECSでは、全てのパラメータをURLに含めてGETメソッドで呼び出しを行い、結果が独自仕様のXMLデータとして返ってきます。GETメソッドは本来情報を取得するものであり、狭義のRESTの考え方ではGETメソッドでリソースが変化することはありえませんが、ECSではショッピングカートの内容の変更などもGETメソッドを利用して行います。ほかにもRESTとして公開されているAPIには、情報の更新を伴わない単なるデータの取得をも（GETではなく）POSTを使って行っているものもあります。

   こうした狭義のRESTには含まれないAPIを（広義の）RESTと呼ぶかどうかに関しては、議論が分かれるところではあります。ただ、実際にRESTとして公開されているAPIの中には、こうしたスタイルのものも多くなっています。