ステートレスとステートフル / Cookie
- ステート=状態
✧ ステートフル:前回のデータを保存して、データ保存した内容を処理結果に反映される仕組みのこと。
- 人とのやり取りに例えると、1回目でやりとりした相手と2回目に会ったとき、やりとり内容を覚えていること。
メリット→状態を保持することができる。1対1のやりとりなら十分。
デメリット→多くの処理を処理するには負担が大きい。一見フルのほうが便利だが、サーバーは一度に多くのクライアントとやり取りをしなければならないため、常に全てのクライアントの状態を保持しなければならないとなると非常に負担が大きくなってしまう。
✧ ステートレス:前回のデータを保存しないで、前回のデータを内容に処理結果に反映させない仕組みのこと。状態を持たないので、セッションという概念を持たない。1回のやり取りで終わり。
- 人とのやり取りに例えると、1回目でやりとりした相手と2回目に会ったとき、やりとりの内容を覚えていないこと。
メリット→多くの処理を素早く処理できる
デメリット→状態を保持できない
- HTTP はステートレス。インターネット上でやりとりが多いHTTPという通信プロトコルは複数のクライアントからの問い合わせが多いので、状態が保持されないステートレスな仕組み。
- ステートフルとステートレスの違いは状態を維持するか・しないかの違い
✧ Cookie:HTTPをステートフルにしてくれる。
例:ショッピングサイトのカートに入れた商品を次ログインしたときにも覚えてくれる。
https://gyazo.com/59d04636cbe88e0fe02a56beca8b8aca
- set-cookieヘッダー
- セッションCookie
- セッションID
一連のやりとり(セッション)を識別するための一意の数字。銀行における受付番号と同じ。セッションIDをクッキーに格納してやりとりをすることによってステートフルな通信ができる。
# Cookieとセッションの違い
セッション=クライアントがWebサーバーに接続してから切断されるまでの一連の行動を表す。
各セッションにはIDが割り振られ、セッションのデータはサーバーに保存される。
セッションIDはブラウザに保存されているため、これをサーバーに渡すことでIDに対応したデータを取り出すことができる。
Cookieでユーザーの判別が行われ、セッションによってそのユーザーがとった行動と結びつけられることで、「通販サイトのカート内商品の保持」といった機能が実現される。
# URI/URL/URN
URI(Identifer)(リクエストURI):リソースを識別するための記述方法
URL(local):リソースの「場所」を示す&リソースを取得する方法
URN(name):リソースの名前(図書館のISBN)
# %エンコーディング
日本語の入ったURLをブラウザで見たときは、日本語https://gyazo.com/42c17f131cc1785e2f4cab7114c3f5e7
これをslackにコピペすると16進数になる=%エンコーディングされてる。
https://gyazo.com/1879ce7ea65e20274876caa500a3b816
メンターさんより。
ステート(状態)について勉強中なのですね〜
書かれていたとおり、ECサイトのカート機能やサイトのログイン状態などは cookie や session を使ってユーザーに状態として持たせていることが多いです。
状態を持たせるのは便利ではあるのですが、不具合とかがあったときに状態を再現するのが難しく、調査で苦労しやすいので、本当に状態を持たせた方が良いところ(実装の都合で持たせるしかないところ)だけで使いたいですね。