『REST』『ステートレス』『URI』…etc

開発の用語としてはごく当たり前に目にし耳にする言葉たちですが、私はこれまで『なんとなく』程度の理解しかできていませんでした。

本記事は、そんな『なんとなく』だった自分の理解をもう一歩深めるために、これまで学んだ内容を私なりに要約した学習ノート（REST ver.）です。

「専門書籍を読んでもいまいちよくわからない」、「本に書いてある内容が難しくてピンとこない」という方に向けた、初学者向けの解説内容となっていますので、専門書籍を読む前に一読し、その後に専門書を読み始めると、あまり抵抗感がなく学習を進められるかもしれません。

そもそもRESTとは？

RESTという言葉自体は「Representational State Transfer」の略です。

それぞれの単語の意味は以下のとおり。

• Representational（具象的な / 表現上の）
• State（状態）
• Transfer（転送 / 移行）

つまりRESTという言葉だけを簡単に説明すれば「リソースやデータの状態を、（JSONやHTMLといった）具体的な形式でやり取りすること」という意味合いになります。

RESTという言葉の意味合いは上記のとおりなのですが、RESTは非常に深い概念で、大きく分けると「Web全体の設計思想」としての側面と、「個別のWeb API/サービスの設計指針」としての側面の両方を持っています。

RESTは、そもそも「World Wide Web (WWW) が、なぜこれほど巨大な規模（ハイパースケール）でうまく機能し続けているのか」を、Webの設計者の一人であるロイ・フィールディングが分析し、その成功の理由を抽出して理論化したものです。

Webの４つの優れたルール

Webは、世界中の誰もが勝手にリソース（図書館でたとえるなら「本」）を追加できる、とんでもなく巨大で、管理者がいない図書館のようなものです。

この巨大な図書館が、なぜ破綻せずに機能し続けているのか？ ロイ・フィールディングは、その理由が以下の4つの「優れたルール」にあると分析しました。

1. URI（ユーアールアイ）：リソース（Webページや画像）の住所を一意に示すルール
2. HTTPメソッド：世界共通言語の「動詞」でリソースを操作するルール
3. ステートレス：図書館の管理人（=サーバー）はいちいち「利用者を覚えない」というルール
4. HATEOAS（ヘイトオス）：今いるページが「次に進むことができるページ」を教えてくれるルール

この優れた４つのルールをそれぞれ詳しく学んでいきましょう。

URI（ユーアールアイ）：リソース（Webページや画像）の住所を一意に示すルール

このルールを先程の図書館の例えにあわせるなら『すべての本（=Webページ、画像、動画）に「固有の整理番号」を振るルール』ともいえます。

もし図書館の本に整理番号（たとえば「P-38-1」など）がなかったら、

• 「3階の奥の、赤い表紙の本」
• 「2階の窓際にある、青くて分厚い本」
• 「昨日追加された、緑色の背表紙の本」

のようにあいまいなキーワードを頼りに探すしかなく、もしタイミング悪く書庫整理などで配置替え（＝サーバーの構成変更）等がされてしまった場合、探していた本（=リソース）は二度と見つからないという困った事態に陥りかねません。

そこでWebでは、すべてのリソース（画像、動画など、Web上のあらゆる情報）に、世界でたった一つの、変わらない「住所」を割り当てるという、とても優れたルールを作りました。

それが Uniform Resource Identifier（ユニフォーム リソース アイデンティファイア)、略してURI（ユーアールアイ） です 。

（※なお、私たちが普段「URL」と呼んでいるものは、このURIの仲間です）

 https://example.com/books/123 （＝123番の本）

この「世界でたった一つの住所（URI）」さえ決まっていれば、世界中の誰もが、他の何億ものリソースと混同することなく、「これだ！」と特定の1ページや1枚の画像を正確に指し示すことができます。

これがルール1としてご紹介していた『URI（ユーアールアイ）：リソース（Webページや画像）の住所を一意に示すルール』であり、Webが成り立つための最も基本的な土台でもあります。

HTTPメソッド：世界共通言語の「動詞」でリソースを操作するルール

しかし、リソースに住所を付けただけではとくに何もできません。その目的のリソースを「どうしたいのか」を伝える手段が必要です。

• 「捨てたい」のか？
• 「読みたい」のか？
• 「新しいリソースを追加したい」のか？
• 「情報を書き換え更新したい」のか？

ここで、もしWeb図書館の設計者が「やり方は各図書館（各サーバー）それぞれで自由に決めていいよ」としていたら、どうなるでしょう？

• Aの図書館サーバーは、「読む」操作を READ /books/123 とする
• Bの図書館サーバーは、「読む」操作を VIEW /books/123 とする
• Cの図書館サーバーは、「読む」操作を SHOW /books/123 とする
• またDの図書館サーバーでは、URI（住所）に操作する内容を含めて GET /showBook?id=123 と表示する

・・・これでは、ブラウザ（閲覧ソフト）は大変です。

Aの図書館に行くってリソース内容を読むときは READ という言葉を使い、B図書館に行ってリソース内容を読むときは VIEW という言葉を使わなければなりません。世界中の無数のサーバーの「独自ルール」を全ていちいち覚える必要があり、膨大な作業と処理が必要になります。そんな大変な作業を行うことは、事実上不可能です。

そこでWebの設計者たちは、リソースの操作方法を、たった数種類の世界共通言語「動詞（メソッド）」に統一することにしました。これがHTTPメソッドです。

その中でも特に重要なのが、以下4つの動詞です。

1. GET ＝リソースの取得｜「見せて」
   • サーバーに「そのリソースをください」とお願いする、一番基本的な操作です。私たちがWebページを見るとき、ブラウザは常にこのGETを使っています。
2. POST ＝リソースの新規作成｜「新しく追加して」
   • サーバーに「新しいデータを登録してください」とお願いする操作です。掲示板への書き込みや、会員登録フォームの送信などで使われます。
3. PUT ＝リソースの置換・更新｜「差し替えて」
   • サーバーにあるデータを「まるごと新しいものに入れ替えてください」とお願いする操作です。
4. DELETE ＝リソースの削除｜「消して」
   • サーバーに「そのリソースを削除してください」とお願いする操作です。

この「動詞」を世界共通にしたおかげで、クライアントとサーバーどちらもが、以下のような大きなメリットを享受できるようになりました。

• クライアント（ブラウザ）側のメリット 🧑‍💻
  • 相手がGoogleのサーバーだろうと、あなたの個人のブログサーバーだろうと、どのサーバーに対しても「GET /...」と言えば「見せて」という意味が必ず通じます。
  • ブラウザは、この数種類の「動詞」の使い方さえ知っていれば、世界中のあらゆるサーバーと会話ができるようになりました。
• サーバー側のメリット 🏢
  • 相手がChromeブラウザだろうと、Safariだろうと、あるいは（APIを叩く）プログラムだろうと、どのクライアントからでも「DELETE /books/123」というリクエストが来たら、「123番の本を消せばいいんだな」と理解できます。

この「世界共通言語」のルールがあるからこそ、Webは無数のサーバーと無数のクライアントが、お互い混乱することなく、シンプルに繋がり合える巨大なシステムとして機能し続けられるのです。

ステートレス：図書館の管理人（=サーバー）はいちいち「利用者を覚えない」というルール

3つ目は、Webという巨大な図書館がうまく機能するためのルールです。

もし、図書館の管理人（＝サーバー）が、図書館の利用者一人ひとりについて「Aさんは今どの棚を見ているか」「Bさんは昨日どの本を借りて、今日は何を探しているか」をすべて記憶し続けなければならないとしたら、どうでしょう？

図書館の管理人はすぐに頭がパンクしてしまいますね。 それに、その「あなたのことを覚えている」図書館の管理人が交代で休憩に入ってしまったら、別の管理人はあなたへの対応の続き（たとえば、「さっき本を探していた」など）ができません。

これでは、多くの利用者をさばくのは不可能です。

そこでWebでは、「サーバーは、リクエストを処理したら、利用者のことはすぐに忘れる」「覚えておかない」という「ステートレス（Stateless ＝ 状態を持たない）」というルールを採用しました。

あなたがサーバーに「GET /books/123（123番の本を読みたい）」と要求すると、サーバーは「はい、どうぞ」と本を渡します。 そして、そのリクエストを処理し終わった瞬間、あなたのことをスッキリ忘れます。

あなたが次に「GET /books/100（100番の本を読みたい）」と要求しても、サーバーは「（さっき123番を読んだ人だな…）」とは一切考えず、「（初めまして、）100番の本ですね、どうぞ」と、完全に新しいリクエストとして扱います。

これが、Webが巨大な規模（スケール）に耐えられる最大の秘密です。

• サーバーが身軽になる：サーバーは「利用者の過去」という重たい記憶を持たなくてよいため、一つひとつのリクエストを高速に処理することだけに集中することができます。
• サーバーをいくらでも増やせる（スケーラビリティ）：そしてこれが一番重要です。 GoogleやAmazonのような超人気サービスには、何千、何万台ものサーバー（図書館でたとえるなら管理人）がいます。 あなたは「123番の本をくれ」と要求します。どのサーバーが対応しても、やることは「123番の本を渡す」だけで同じです。Aサーバーが忙しければ、あなたの次のリクエストはBサーバーが対応すればいいのです。 どのサーバーもあなたのことを覚えていないからこそ、どのサーバーが対応しても同じ対応ができる。これが、何億人ものリクエストを同時にさばける理由です。

補足：ログイン情報やカートの記憶

でもあなたはこう不思議に思うかもしれません。

「普段使用しているWebサイトは私のことを覚えてるよ？」

ですがそれは、サーバーという管理人があなたの個人情報を覚えているわけではありません。

あなたの分身（つまりこの場合はWebで使用している「ブラウザ」）が「会員証（Cookieなど）」を毎回のリクエストに添付して、「私、会員番号XXXですけど、この本ください」と毎回自ら名乗っているのです。

つまりサーバーは記憶をしておらず、その「会員証」を見て、その場限りで「あ、XXXさんですね」と判断しているだけにすぎないというわけです。

HATEOAS（ヘイトオス）：今いるページが「次に進むことができるページ」を教えてくれるルール

これが、Webがうまく機能する最後の、そして最も重要なルールです。

HATEOAS (Hypermedia as the Engine of Application State) という名前は一見するとなんだかとても難しそうですが、やっていることはWebではごく当たり前のことで、私たちが普段ブラウザでリンクをクリックしている、まさにあの行為のことを指しています。

つまり、Webページ上にあるリンクタグ（<a>タグの仕組み）が、私たちが次のページに移動するための「原動力（Engine）」になっている、という意味です。

「もし、HATEOAS（つまりWebページ上にある<a>タグリンク）がなかったら？」と一度想像してみてください。今回は図書館の例え話にしてしまうとわかりにくくなってしまうので、実際にWeb使用時をイメージしてみましょう。

たとえばあなたが、あるニュースサイトのトップページを見ているとします。

でも、そのページには「スポーツ」「政治」「経済」といったクリックできるリンク（<a>タグ）が一切なく、ただの文章（ニュースの見出し）だけが書かれています。

そこであなたがスポーツニュースを読みたくなったとします。

でもページにはリンクが設置されていないので、「このサイトのスポーツコーナーのURLは、確か .../sports.html だったな…」と、URL（URI）を「暗記」して、ブラウザのアドレスバーに直接ぽちぽちと打ち込むしか手がありません。

でももしサイト運営者がURLを .../new-sports.html に変更していたら・・・、またはあなたの記憶が間違っていて、URLを間違えて覚えてしまっていた場合・・・あなたはもうそのスポーツニュースのページにアクセスすることができません（404エラー）。

これではあまりに不便すぎますよね。

でも実際のWebはもちろん違います。 ニュースサイトのトップページを見れば、そこには「スポーツ」「政治」といった容易にクリックできるリンク（道しるべ）が必ずあります。

私たちは、その「スポーツ」というリンクをクリックするだけでページが切り替わり、見たかった「スポーツ」ニュースのページへ簡単に遷移（せんい）することができます。

これこそが HATEOAS です。

「なぜ、HATEOSがもっとも重要なルールなのか？」

この「リンクを辿る」という単純なルールが、Webを驚くほど強力なものにしています。

• メリット①：利用者は「サイトの配置（地図）」を覚えなくていい
  • あなたは、そのサイトの全ページのURLを暗記する必要は一切ありません。 ただ、「今いるページに表示されたリンクをクリックする」というルールさえ知り、それを実行さえすればいれば、サイト内を自由に見て回れます（Webサーフィンできます）。
• ② サイト運営者は「変更」にめちゃくちゃ強い
  • これも非常に重要です。 もしサイト運営者が「スポーツ」コーナーのURLを .../sports.html から .../new-sports.html に変更したとします。もしURLをアドレスバーに手打ちするしか手段しかなく、そのうえ変更後のURLも知るすべがなかったら、更新された新しいWebページにアクセスすることはできません。
  • でもHATEOAS（リンク）のルールが適応されていれば大丈夫。サイトの運営者は、トップページの「スポーツ」ニュースのリンク先（hrefの中身）を新しいURLに書き換えるだけで済みます。 あなたは、いつも通りトップページの「スポーツ」ニュースのリンクをクリックするだけで、特に何も意識しなくても、自動的に新しいURLにたどり着けます。

つまりHATEOASとは、「Web利用者が『次にどのページを見に行くことができるか』『どのページに遷移できるか』といったことに頭を悩ませなくてもいい」という、私たちが当たり前に使っているWebサーフィンの仕組みそのものなのです。

【まとめ】Web全体の設計思想｜理論としてのREST

「Web全体の設計思想｜理論としてのREST」とは、ロイ・フィールディングが見つけた「Webが巨大になってもうまく機能し続けるための4つの優れたルール」のことでした。

1. URI（ユーアールアイ）：リソース（Webページや画像）の住所を一意に示すルール
2. HTTPメソッド：世界共通言語の「動詞」でリソースを操作するルール
3. ステートレス：図書館の管理人（=サーバー）はいちいち「利用者を覚えない」というルール
4. HATEOAS（ヘイトオス）：今いるページが「次に進むことができるページ」を教えてくれるルール

つまりWebは、この４つのルールを守っているからこそ今も成長し続けられる、というわけです。

ここまでのご紹介が、『Web全体の設計思想』としてのRESTの4つのルールでした。

さて、Web全体がRESTの原則でうまく機能しているなら、「API」も、同じ原則に従って作ればうまくいくはずではないでしょうか？

そのひらめきこそが応用・実践としてのREST、つまり「RESTful API」の考え方です。

そもそも「API」とは？

API（エーピーアイ）は、「Application Programming Interface（アプリケーション・プログラミング・インターフェース）」の略です。

簡単に言うと、「ソフトウェアやプログラム同士が、お互いに『会話』したり、機能を使ったりするための『窓口』または『受付』」のことです。

🍽️ 「レストランのウェイター」の例え

APIを理解するのには、よく「レストランのウェイター」に例えられたりもします。

👩お客さん：あなたのアプリ（例: スマホの天気予報アプリ）

👨‍🍳料理人：サービスを提供するサーバー（例: 天気予報会社のデータベース）

👨‍⚖️ウェイター： API

あなたは「明日の東京の天気が知りたい」とウェイター(=API)に、決まった形式で注文（リクエスト）します。

ウェイター(API)は、その注文をキッチン(=サーバー)に伝えます。キッチンは「明日の東京は晴れ」という料理（=データ）を作ります。

最後に、ウェイター(API)がその料理（データ）をあなたの元へ運んできます（レスポンス）。

なぜAPIが重要なのか？

この仕組みの最大のポイントは、あなた（お客さん）は、キッチンの内部（つまり、どうやってデータが作られているか）を一切知らなくてもよいことです。

ウェイターという「公開された窓口」を通じて、決まったルールで注文さえすれば、誰でも目的の料理（データ）を得ることができます。

Webの世界では、

• Googleマップの地図データを、あなたのアプリに表示させるための窓口 (API)
• YouTubeの動画データを、あなたのサイトで再生するための窓口 (API)

のように、あらゆるサービスがAPIを公開することで、色々なプログラムがお互いの機能を便利に使い合えるようになっているのです。

つまり「RESTful API」というのは、この「ウェイター（API）の動き方」に関する、「とても効率的で、分かりやすい接客ルールの体系」（= 4つの原則）のことだと思ってください。

そして4原則のなかでも特にイメージしにくい、HATEOASの説明に移りたいと思います。

「Webサーフィン」を「プログラム」にさせる

では先ほどのHATEOASの例を思い出してください。

• 人間 🙋‍♀️: ブラウザでニュースのトップページを見て、「スポーツ」というリンク（<a>タグ）を見つけ、それをクリックして次のページに進む

これを、プログラムに置き換えるだけです。

• プログラム 🤖: APIの /（トップ）にアクセスしたら、サーバーから以下のようなJSONが返ってくる

{
  "message": "APIへようこそ",
  "links": [
    {
      "rel": "sports",  /* ←関係性（スポーツ） */
      "href": "https://api.example.com/sports-news" /* ←リンク先URI */
    },
    {
      "rel": "politics", /* ←関係性（政治） */
      "href": "https://api.example.com/politics" /* ←リンク先URI */
    }
  ]
}

このレスポンスを見たプログラムは、人間と同じように考えます。

「なるほど！次に『スポーツ』の情報を知りたければ、この links の中にある rel: "sports" の href（URI）にアクセスすればいいんだな」

これが、APIにおけるHATEOAS（リンクを辿る）の実践です。

なぜ、APIでHATEOASが重要なのか？

もし、このJSONに links がなかったらどうでしょう？

APIを使う側のプログラムは、「スポーツニュースのURLは、.../sports-news だ」と、URL（URI）を「暗記（ハードコード）」しなければなりません。

もしAPIの提供側（サーバー）がURLを .../new-sports/ に変更したら、そのURLを暗記していた世界中のアプリが一斉に動かなくなります。大変なことですよね。

HATEOAS（JSONにリンクを含める）というルールを守れば、サーバーがURLを変更しても、links の中身を書き換えるだけです。 アプリ（プログラム）は、いつも通りレスポンスの中のリンクを辿るだけなので、サーバー側の変更に全く影響されません。

RESTful APIの原則まとめ

つまり、「RESTful API」を作るというのは、Web全体の成功ルールを、プログラム間の通信に応用するということです。

1. URIでリソースを示す
   • GET /users/123 （ユーザー123番）のように、データ（リソース）に一意な住所を割り当てる。
2. HTTPメソッドで操作する
   • 「ユーザー123番を消したい」なら DELETE /users/123
   • 「ユーザー123番を見たい」なら GET /users/123
   • URIに「動詞」（deleteUserなど）を入れず、HTTPメソッドで操作を表現する。
3. ステートレスを保つ
   • サーバーはアプリの状態を「記憶」しない。リクエストに必要な情報（「私は会員XXXです」という認証トークンなど）は、アプリ側が毎回送る。
4. HATEOASを実践する
   • レスポンスのJSONの中に、「次にできること」へのリンク（URI）を含める。

これら4つの原則を守ることによって、「シンプルで、変更に強く、スケールしやすい（規模を大きくしやすい）システム」、つまり「長生きする、ムダのない設計をもったシステム」をつくれるようになるのです。

本記事では、「なんとなく」だったRESTの理解を深めるため、RESTの2つの側面について学習をしました。

1. 理論としてのREST

RESTとは、Webがなぜこれほど巨大な規模で成功しているのかを分析し、その成功の理由を抽出した「Web全体の設計思想」です。

Webは、以下の4つの優れたルールを守ることで、破綻することなく機能し続けています。

1. URI: リソース（情報）に「世界で一つの住所」を割り当てるルール。
2. HTTPメソッド: GET (見せて), DELETE (消して) など、「世界共通の動詞」でリソースを操作するルール。
3. ステートレス: サーバー（管理人）は利用者を「覚えない」ルール。これにより、サーバーは身軽になり、いくらでも台数を増やして対応できます（= スケールしやすい）。
4. HATEOAS: ページが「次に進める場所」へのリンク（道しるべ）を教えてくれるルール。利用者はURLを暗記する必要がなく、運営者はURLの変更に強くなります。

2. 実践としてのREST (RESTful API)

RESTful APIとは、このWebの4つの成功ルールを、プログラム間の会話（API）に応用する設計指針です。

1. URIでリソースを示す
   • GET /users/123 （ユーザー123番）のように、データ（リソース）に一意な住所を割り当てる。
2. HTTPメソッドで操作する
   • 「ユーザー123番を消したい」なら DELETE /users/123
   • 「ユーザー123番を見たい」なら GET /users/123
   • URIに「動詞」（deleteUserなど）を入れず、HTTPメソッドで操作を表現する。
3. ステートレスを保つ
   • サーバーはアプリの状態を「記憶」しない。リクエストに必要な情報（「私は会員XXXです」という認証トークンなど）は、アプリ側が毎回送る。
4. HATEOASを実践する
   • レスポンスのJSONの中に、「次にできること」へのリンク（URI）を含める。

こうしてRESTの設計思想と設計指針知ることで「Webがなぜこれほど上手くいっているのか」という成功の秘密を知ることができ、ひいては本日学んだことを生かして自分の作るシステムに応用できるようになる。

そんなふうに、どなたかのお役に立てたら幸いです！

なお本記事は以下２冊を参考に作成しています。

• イラスト図解式 この一冊で全部わかるWeb技術の基本 第2版
• Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESSプラスシリーズ)

原著にはここで触れる何倍もの知識と知見が詰まっています。

本記事はあくまで私個人の解釈メモとなっておりますので、内容をよりくわしく正確に知りたい方は、ぜひ書籍を手に取ってみてください！

ではここまで読んでいただき、ありがとうございました

mizo

「(株)現場サポート」という会社で働きながら、オンラインスクール「フィヨルドブートキャンプ」でプログラミングを学習しています。