Webサービスを開発する上で絶対に知らないといけない基礎用語の意味を自分なりにまとめました。
- リクエスト
- レスポンス
- プロトコル
- ステートレス
- ステートフル
- クッキー
- セッション
リクエスト, レスポンス
Webアプリケーションの通信は「クライアントサイドのリクエストと、サーバーからのレスポンス」で成り立っています。
図はこちらになります。
私達はPCや携帯電話で様々なWebサイトにアクセスをして毎日様々なWebページやサービスを利用しています。その仕組みは意外と単純なものになります。
-
クライアントサイドと言われるPCや携帯電話から、各WebサービスやWebページのある「サーバー」にアクセスをして
「〜ページをください」というリクエストを送っています。 -
そのリクエストを受け取ったサーバーは、「こちらが、そのページです」といった具合に対象のページのhtmlファイルを返却します。(
レスポンス)
これが、WebサービスやWebサイトにアクセスをしたとき、コンピューターたちは、どのような動きをしているのか簡単にまとめたものになります。
プロトコル
冒頭でも記述をしましたが、Webアプリケーションの通信は「クライアントサイドのリクエストと、サーバーからのレスポンス」で成り立っています。言い換えると、クライアントサイドとサーバーが「通信」することによってWebアプリケーションは成り立っています。
その時の「通信の取り決め、ルール」がプロトコルになります。
つまり、私達は知らない間に「プロトコル」に則ってインターネットを利用していますし、Webアプリケーションの開発者もこの「プロトコル」を守る形で開発をしています。
ちなみに、プロトコルには様々なものがあります。有名なものは以下です。
- HTTP：WebサーバーとWebクライアントが通信をするための共通のプロトコル
- TLS/SSL：安全な通信をやりとりすための使用するプロトコル
- IMAP：メールサーバ上でメールを管理するために用いるプロトコル
- SSH：外部サーバーに接続するためのプロトコル（通信内容は暗号化される）
ステートレス
ここからはプロトコルの中でもっとも有名なHTTPというものについて深堀りをしていきたいと思います。
上で「HTTP」とは、「WebサーバーとWebクライアントが通信をするための共通のプロトコル」という記述をしました。
つまり「通信」に関するプロトコルの代表的なものになります。
この「HTTP」というプロトコルの通信にはステートレスという特徴があります。
ステートレス（Stateless）？
とは何でしょう。ちなみに対義語は「ステートフル(Stateful)」になります。
とりあえず英和辞書で意味を調べてみます。
この「ステートフル」「ステートレス」は、IT初心者には非常に難しい概念になるため、様々な用語の解説のサイトを見ても
自分は理解できませんでした。そのため、私は具体的な例を考えながらこの概念を理解しています。
【例】
ステートレスとステートフルは「自動販売機」と「高級ステーキなどのレストラン」の違いのように私は理解しています。
ステートレス・・・・自動販売機
ステートレス・・・・高級レストランのウエイター
自動販売機の場合、ボタンを押せば、自分が飲みたいという飲み物が出てきます。
同じ自動販売機に毎日通ったとしても、自動販売機は自分が普段買っている飲み物を覚えてもくれませんし、今日のおすすめのドリンクなども提案してくれませんし。
→つまり、どんなお客様に対しても全く同じ反応をする（レスポンスを返す）ということになります。これがステートレスの考え方です。
一方で、高級レストランの場合はどうでしょう。
高級レストランの場合は、そのお客様が初めて訪れたときからの注文履歴やそのお客様のアレルギー情報、
好き嫌いの傾向などをメモしたデータを保存しているところが多いです。
実際に、飲み物について、なくなりそうな場合は、自動で水を注いでくれます。
アレルギー情報を考慮したメニューを提供してくれます。
間違って食事を注文してしまった場合でも、一定時間内であればキャンセルできる場合も多いです。
常連客であれば「いつものお願いします」というフレーズだけでも注文が可能になることもあります。
→つまり、お客様の「状態」によって、サービス内容が異なってきます。これがステートフルの考え方になります。
話は戻りますが、HTTPは「自動販売機」のような通信を行います。
リクエストするクライアントサイドが、過去に何度もそのWebサイトを訪れたことがあっても、
初めて訪れたとしても誰に対しても平等に同じレスポンスを返します。
もし、クライアントサイドが「常連」で毎回同じボタンを押して同じジュースを買っていたとします。たまたまいつもと違うジュースのボタンを押し間違ってしまった場合でも、「いつもと違いますが本当に大丈夫ですか？」といった警告は出ずに、押されたボタンの飲み物が提供されてしまいます。
「常連」のクライアントサイドは間違ったことに気がついても返品できません。もしいつものジュースが飲みたい場合は、再度お金を入れて飲み物を買わないといけません。
ステートフル
ステートレスについては上記の記述でどのように実現されるということがわかりました。では、「ステートフル」はどうやって実現されるのでしょうか？
そもそも「ステートフル」が必要な場面とはどのようなWebサービスでしょうか？
最も有名なものは「Webアプリケーションのログイン機能」ではないでしょうか？
インターネットショッピングモールに、ログインした時、
そのアカウントが過去に購入した商品履歴や、お気に入りに登録した商品も見ることができます。つまりそのアカウント専用のページが表示されます。また、一定期間であれば他のWebサイトに遷移してしまっても再ログインせずにログイン後のページに戻ってくることができます。
以上のような内容が「ステートフル」を存分に活用したWebサービスになります。
クッキー（Cookie）, セッション（Session）
では、「ステートレス」が前提の「HTTP」を利用してどのように「ステートフル」を実現するのでしょうか？
上記を実現するために、必要となるのがCookie（クッキー）とSesion（セッション）という技術になります。
仕組みは以下になります。
-
クライアントサイドがサーバーリクエストを実施したときに、サーバーはSessionという情報を自分自身のサーバーの中に保存します。
その後 サーバーはSessionIDというSession情報に紐づけるIDを「Cookie」と言われるHTTPを拡張して作られた技術を使って付与します。 少し難しい書き方になってしまいましたが、Coookie自体はただのテキストファイルなので、そのテキストファイルにSessionIDを書き込んでアクセスしたWebブラウザ（SafariやChrome）に渡すというイメージになります。
-
クライアントサイドは２回目以降アクセスするときには、そのアクセスと同時にCookieをサーバーに送ります。
-
サーバー側はそのCookieを受け取って、自分のサーバーに中に保存されているSession情報を確認して、Session情報があった場合には、そのクライアントサイド専用のレスポンスを返します。
このような仕組みがあるからこそ、HTTPプロトコルを使用しながらでも「ステートフル」な通信が可能になっています。
イメージを掴んだところで、新しい用語の解説です。
Session（セッション）・・・・・クライアントのログイン→様々な取引→ログアウトまでの一連の流れのこと。Sessionは
サーバー側で保持して、最終的にSessionIDを発行してセッション情報と紐づけて管理する。
Cookie（クッキー）・・・・・HTTP通信を拡張して作られた技術。CookieにSessionIDを記載することで、HTTPプロトコルでもステートフルの通信が実現可能