Cookieこの節に関しては「である」調では書きません。中でも議論に上ることが多いので、明確に記述することが難しいためです。調べた上での「自分の」理解としてまとめておきます。間違いに気付いたら都度直していきます。原則の1つに「ステートレス性」があります。ステートレスなプロトコルなので、この原則は自然です。なしにリクエストを送信した場合、大抵は認証ページにリダイレクトされてしまいます。アドレス可能性を失っていることになるからです。使うことはセキュリティの観点から無理なわけです。違反しないようにするにはどうしたらいいでしょうか。p.209」には以下のように書かれています。よれば、アプリケーション状態はすべてクライアント側で管理しなければならない。これがステートレスの意味することである。アプリケーションに状態がないのではなく、リクエストをそれぞれ独立させることができる。クライアント/サーバセッション自体は状態を維持しない。ベースでのセッション管理だと思います。状態をなるべくクライアントに持たせる実装になっています。有効かどうかの状態を管理する必要がなくなります。認証等のようにステートレスな認証に近い形になります。デメリットとして、セキュリティ面での問題が起こりやすくなります。ステートレスなのか」)。そこによれば、ステートレスのそもそもの目的は「シェアードナッシングアーキテクチャによるスケーラビリティの確保」にあります。スケーラビリティをなるべく確保できる方向に設計することが大切。その実現方法の1つとして、スティッキーセッションが上げられていました。スティッキーセッションならば、リクエストを処理するサーバをスケールアウトしていくことは可能です。サーバを増やした際に無効になるセッションが存在する可能性はありますが、認証のためだけに用いられているセッションならば許容できる場合が多いはずです。設計ではアーキテクチャ上の決定は名詞の領域に集まる。実現する統一性は標準化作業に大きく貢献する。タグ」を使って利用することができる。サーバ間で何も共有しない。ついて調べた上での感想について書いていきたいと思います。設計が大きな部分を占めることになります。リソースに対するメソッドの設計も名前も既に決められているからです。おいては、適切なリソースをどう導出するかが重要であり、この過程をリソースモデリングといいます。おいては、「その処理によって得られるリソースは何なのか」を意識する必要があります。Architecture」といいます。