【今日のQ&A】RESTってなに？中編【ソフトウェア設計】

こんにちは、@codeship_techです。

前回に引き続き、RESTについて解説していきます！

前回の解説を見ていない方は解説をより理解するために、先に前編を見ることをお勧めします。

【今日のQ&A】RESTってなに？前編【ソフトウェア設計】

(前編の続き)

　3.ステートレスサーバ

「ステート: state」とは状態という意味です。
すなわちステートレスサーバとは、「サーバがクライアントの状態を持たない」という意味です。

クライアントがリクエストを送るとき、クライアントの記録している情報は逐一リクエストに送ることを取り決めます。

それによりサーバはそのリクエストに対するレスポンスを返したのち、リクエストを保持することなく破棄することで、「単にリクエストが来たらそれに対応するレスポンスを返す」装置として実装することができます。
実装が簡便になるのです。

ステートレスの反対は「ステートフル」と言い、サーバがクライアントの状態を保持したまま通信を続けます。

ステートフル・ステートレスとは直感的には以下のようなことを指します。
あなたはファミリーレストランで注文を行うお客さんです。これをWebにおける「クライアント」とします。

注文を受ける店員は「サーバ」とします。そのやりとりがもし「ステートフル」だとこのようになります。

ステートフルなクライアント・サーバシステム

客：「注文をお願いします」
店員：「ご注文をお伺いします」
客：「和牛ステーキセットを1つ」
店員：「和牛ステーキセットですね、焼き加減はいかがいたしましょうか」
客：「ミディアムで」
店員：「ステーキソースはいかがいたしましょうか」
客：「バーベキューソースで」
店員：「メインがパンとライスからお選びいただけますがいかがいたしましょうか」
客：「メインはライスで」
店員：「サラダドレッシングは和風とオーロラからお選びいただけますがいかがいたしましょうか」
客：「オーロラドレッシングサラダで。注文は以上です」
店員：「かしこまりました」

色々な手続きをこなす普通のやりとりです。
これがもし「ステートレス」だと以下のようになります。

ステートレスなクライアント・サーバシステム

客：「注文をお願いします」
店員：「ご注文をお伺いします」
客：「和牛ステーキセットを1つ、注文をお願いします」
店員：「和牛ステーキセットですね、焼き加減はいかがいたしましょうか」
客：「ミディアムで和牛ステーキセットを1つ、注文をお願いします」
店員：「ステーキソースはいかがいたしましょうか」
客：「バーベキューソースのミディアムで和牛ステーキセットを1つ、注文をお願いします」
店員：「メインがパンとライスからお選びいただけますがいかがいたしましょうか」
客：「メインはライスで、バーベキューソースのミディアムで和牛ステーキセットを1つ、注文をお願いします」
店員：「サラダドレッシングは和風とオーロラからお選びいただけますがいかがいたしましょうか」
客：「オーロラドレッシングサラダで、メインはライスで、バーベキューソースのミディアムで和牛ステーキセットを1つ、注文をお願いします。注文は以上です」
店員：「かしこまりました」

あまりに冗長なやりとりですよね。

「ステートフル」な状態では、店員が客の注文状態を覚えていました。
だから客は繰り返し同じことを言う必要がなく、聞かれたことに対する情報のみを提供します。

この店員(サーバ)が保持しておく客(クライアント)の以前の情報を「セッション」や「状態」と言います。

「ステートレス」な状態では、店員は客の注文を保持できません。
なので客が今までの情報をすべてひとまとめにして逐一提供し直す必要があります。

PCのサーバは上記の店員とは違い、同じ時間に複数のクライアントからのリクエストが集中するかもしれません。

状態を覚えておくサーバは、一つのリクエストを対応している間は他のリクエストに対応することができません。
そこでクライアントがリクエストごとに全ての情報を逐一提供することで、サーバは複数のリクエストに対する応答(レスポンス)を送ることが出来ます。

すなわちステートレスサーバは、サーバが一度に処理するリクエスト数を増やす観点から合理的なのです。

現実にはサーバはクライアントのログイン状態などを保持しますので、昨今のWebサーバは完全なステートレスではないとする主張が優勢です。