「RESTとはなんぞや？」を４原則から考えてみる #REST-API

はじめに

この記事では、「RESTとはなんぞや？」という初歩的でありながら、非常に大事な疑問について解説していきます。
※ただし、その具体的な実装手段などには触れずに、主にRESTの4原則をわかりやすく説明することにフォーカスします。

では今回は「RESTミリしら」の人をターゲットに、以下の4原則について、あえてWEBサービス以外の日常生活を例に解説していきます。

アドレス可能性 (Addressability)
ステートレス性 (Stateless)
接続性 (Connectability)
統一インターフェース (Uniform Interface)

そもそもRESTとは

REST（REpresentational State Transfer）は、Webサービスの設計思想の一つです。
そしてWebサービスとは、インターネット上で情報を提供するシステムのことです。例えば、Amazon, X(旧Twitter), QiitaなどといったウェブサイトがWebサービスの一例です。
つまり無数にあるWebサービスの中の一つに、RESTに基づいて設計されたWebサービスが存在しているということですね。

このRESTには、以下のような４つの原則（特徴）があります。

四原則

1. アドレス可能性 (Addressability)

アドレス可能性とは、提供する情報がURI（Uniform Resource Identifier）を通して表現できることを意味します。それぞれの情報は一意なアドレスを持っており、そのアドレスを使って特定の情報にアクセスすることができます。

ちなみにここで言っている情報とは、ROA(リソース指向アーキテクチャResource Oriented Architecture)では、リソースと呼ばれるものです。
リソースとは、情報の集合体のことで、インターネット上に存在するウェブページや画像、動画、ユーザー情報などがすべてリソースとして扱われます。

例えば、インターネット上のウェブページは、URL（Uniform Resource Locator）と呼ばれるURIを使って表現されます。
URLを知っていれば、そのページにアクセスすることができるのはこのおかげです。
つまり皆さんの慣れ親しんだURLはURIという概念の一部なんですね。

例） URI＝電話番号

ではまず、URIを電話番号に例えて考えてみましょう。

あなたは普段、友人や家族、会社など様々な人に電話をかけているはずです。
その際電話番号がわからなければ、その人に電話をかけることができませんよね。

このように、電話番号は、特定の人(もしくはその人が持つデバイス)を表現するためのアドレスとして機能しています。
URIも同じように、特定の情報を表現するためのアドレスとして機能しているので、それが存在しないと、その情報にアクセスすることができずに困ってしまいます。

2. ステートレス性 (Stateless)

RESTは、ステートレスなクライアント/サーバプロトコルです。ステートレス性とは、情報のやり取りにおいて状態を保持せず、各リクエストやレスポンスが完結していることを意味します。つまり、リクエストやレスポンスには独立した情報が含まれており、それ自体で解釈することができます。

例えば、ウェブサイトのフォーム入力の場合、各リクエストには入力された情報が含まれており、サーバはそれを処理してレスポンスを返します。それぞれのリクエストやレスポンスは、他のリクエストやレスポンスとは関連性を持っていません。

反対に、ステートフルなプロトコルでは、リクエストやレスポンスに状態を持たせることができます。例えば、チャットアプリの場合、各リクエストには、チャットの履歴が含まれており、サーバはそれを処理してレスポンスを返します。この場合、各リクエストやレスポンスは、他のリクエストやレスポンスと関連性を持っています。

……先ほどのURIと比べて少しイメージしづらいですよね。
少々長くなりますが、以下の例で丁寧に説明していきます。

例）食堂のおばちゃん(ステートフル代表) VS 食券制のラーメン屋(ステートレス代表)

では、ステートレス性(ないしはステートフル性)を、食堂のおばちゃんと食券制のラーメン屋に例えて考えてみましょう。

地域密着型食堂のおばちゃんは、馴染みのお客さんが「いつものアレね」と注文すると、そのお客さんがいつも頼んでいるものを覚えているので、意図した定食を提供してくれることでしょう。
しかしながら、食券制のラーメン屋では、お客さんがいつも頼んでいるものを覚えていることはありません。お客さんは、毎回食券を買って注文する必要があります。

このように、食券制のラーメン屋は、お客さんの情報を保持していません。お客さんは、毎回食券を買って注文する必要があります。これがステートレス性です。

これだけ聞くと、食券制のラーメン屋の方がお客さん(ユーザー)にとって不親切に感じるかもしれません。しかし、食券制のラーメン屋は、お客さんの情報を保持していない分、お客さんがどんなラーメンを頼むかということに意識を向けずに済みます。これは、食券制のラーメン屋がステートレスであることによって、効率的にラーメンを提供することができるということです。
反対に、食堂のおばちゃんは、お客さんが過去に何を注文してきたのかという情報を保持することや、そもそもお店に今どのお客さんが来店したかなどに意識を向けなければなりません。これは、食堂のおばちゃんがステートフルであることによって、食事の提供のみに集中することができないということを表します。

また食堂のおばちゃんの記憶力にも限界はあります。近くにビルでもできてお昼時の客数が多くなりすぎると、お客さんの情報を保持することができなくなります。これは、食堂のおばちゃんがステートフルであることによって、大量のお客さんに柔軟に対応することができないということを表します。
(これこそが「ステートフルなシステムはスケーラビリティが低い」と言われる所以です。)

3. 接続性 (Connectability)

接続性とは、情報の内部に他のリソースへのリンク(ハイパーリンク)を含めることができることを意味します。これによって、関連する情報に対して簡単にアクセスすることができます。

例えば、ウェブページ上のリンクは、接続性の代表例です。あるページから別のページへのリンクを辿ることで、関連した情報にアクセスすることができます。

例）Youtubeの概要欄

これはイメージしやすいかもしれないので、Youtubeの概要欄を例にサクっと考えてみましょう。

Youtubeの概要欄には、動画自体の説明文以外にも、その動画の次回作や投稿者のSNSアカウントのURLなど様々なリンクが記載されているはずです。
これらのリンクを辿ることで、関連した情報にアクセスすることができます。
つまり、そういったYoutubeの概要欄は、接続性を持っていると言えます。

4. 統一インターフェース (Uniform Interface)

統一インターフェースは、RESTの最も重要な原則の一つです。統一インターフェースは、情報の操作（取得、作成、更新、削除）を統一メソッドを使用して行うことを指します。
その代表例がHTTPメソッド（GET、POST、PUT、DELETE）です。

これによって、サーバとクライアントが共通のインターフェースを持ち、リソースに対して一貫した方法でアクセスすることができます。

例）方言

例えば、この世の中に標準語メソッドと関西弁メソッドがあるとします。(以下からは普通に標準語と関西弁と略します)

そして関西弁の中には「なおす」という特殊なメソッドがあります。
「なおす」は、標準語では「修正する」という操作に相当します。
しかしながら、関西弁ではそれ以外にも「元あった場所に戻す」という操作を表すこともあるのです。

つまりこのことに関して、標準語と関西弁では、同じメソッド名を使っているにも関わらず、場面によって意味が異なってしまい、統一インターフェースとしては機能していないと言えます。

このせいで、標準語と関西弁それぞれ別のインターフェースに慣れ親しんだユーザーが、相手のインターフェースを触れ合う場合には混乱してしまう可能性があるのです。

おわりに

この記事では、「RESTとはなんぞや？」という疑問について解説してみました。
RESTは、アドレス可能性、ステートレス性、接続性、統一インターフェースの四原則に基づいた設計思想です。
これらの原則を理解することで、より効率的かつ柔軟なシステムを構築することができます。

具体的にこれらをどう実装するかは、また別の機会に。

参考文献

RESTful APIとは何なのか(Qiita)
- 非常にわかりやすかったので、この記事を書く際にも参考にさせていただきました。
RESTful Webサービス(オライリー出版)
- 少し古いですが、思想や原則について学べます。個人的には読みづらかったのであまりお勧めできません。
Web API: The Good Parts(オライリー出版)
- 実際にREST APIを実装する前に読むべき良い本だと思います。