セッションはRESTfulnessに違反しますか？
1. 序章
最新のWebアプリケーションのほとんどは、何らかの形でセッションを使用します。 セッションは通常、ユーザーエクスペリエンスを向上させるために、クライアントに関する情報（認証、カスタマイズされた推奨事項、ショッピングカートなど）を保存するために使用されます。
同時に、多くのアプリケーションはRESTful原則を使用して構築されています。 このチュートリアルでは、セッションを定義するものと、セッションがRESTfulnessの原則に違反しているかどうかを詳しく見ていきます。
2. セッションとは何ですか？
セッションという用語は、プログラミングの世界ではさまざまな意味を持っています。 最下位レベルでは、2つのデバイス間の接続を制御するTCP接続を参照できます。
アプリケーションの場合、セッションは、同じクライアントとの複数の対話にわたって状態を追跡するための単なる方法です。 最近の多くのアプリケーションはHTTPを使用してアクセスされますが、プロトコル自体はステートレスです。 つまり、アプリケーションは独自に何らかの形式のセッション管理を実装する必要があります。
通常、セッショントラッキングでは、最初にリクエストを行うときに、各クライアントに一意の識別子を割り当てます。 次に、クライアントは、サーバーに送信する後続の要求にそのIDを含めます。 サーバー側では、識別子を使用して、そのクライアントに関する詳細を保存および検索できます。
2.1. セッションの一般的な使用法
セッション状態は、最新のWebアプリケーションでは回避するのが困難です。 これは、セッションによってWebサイトのユーザーエクスペリエンスを向上させる多くの機能が有効になるためです。
- ユーザーのログインステータスを記憶する
- ショッピングカートの内容を複数のデバイスに保存する
- さまざまなサイト検索での検索フィルターの呼び出し
これらはすべて、サーバーがクライアントとの以前のやり取りの詳細を保存する必要があります。 また、クライアントは変更できるため（差分デバイス、Webブラウザーなど）、この状態を保存するための唯一の一貫した場所はサーバー上です。
2.2. クッキー
セッションはCookieと同じではないことに注意することが重要です。 Cookieは、クライアントとサーバーの間でセッション情報を交換するための1つのメカニズムにすぎません。 ただし、Cookieは唯一の方法ではなく、セッションの追跡にのみ使用されるわけでもありません。
カスタムヘッダー、クエリパラメータ、またはその他のHTTP機能をいくつでも使用して、同じ結果を得ることができます。
3. RESTと状態
REST は、REpresentationalStateTransferの略です。 これは、 Roy Fieldingの論文で説明されているアーキテクチャスタイルであり、大規模でスケーラブルなクライアントサーバーシステムを構築するための理想的なソフトウェアアーキテクチャについて説明しています。
RESTのコンテキストでは、stateという用語がいくらか過負荷になっていることに注意することが重要です。 私たちが気にする状態には2つのタイプがあります：
- 特定のクライアント/サーバー相互作用の状態
- リソースの状態
私たちがセッションについて話すとき、私たちは通常前者について話します。 クライアントとサーバー間の相互作用の状態は、通常、1つまたは複数のセッション状態について話すときに意味されます。
一方、リソースの状態は、常にサーバーによって維持されます。 クライアントは、さまざまな表現を要求したり、リソースに変更を送信したりできます。 ただし、サーバーは最終的にリソースの状態を維持する責任があります。
3.1. ステートレス制約
RESTfulシステムの多くの制約の中には、サーバーがこの要求を満たすために必要なすべての情報がすべての要求に含まれている必要があるというものがあります。 つまり、クライアントからサーバーへのすべての要求は、以前の要求の知識に依存してはなりません。
具体的には、RESTfulシステムに関するセッション状態についてフィールディングが言ったことは次のとおりです。
クライアントからサーバーへの各リクエストには、リクエストを理解するために必要なすべての情報が含まれている必要があり、サーバーに保存されているコンテキストを利用することはできません。 したがって、セッション状態は完全にクライアント上に保持されます。
ここで、フィールディングがクライアントの状態とサーバーの状態をどのように区別しているかに注目してください。 サーバーはリソースの状態を管理でき、管理する必要があります。 たとえば、従業員の住所やユーザーの注文履歴などです。 この状態はすべてリソースに関連付けられており、最終的にはサーバーがそのリソースに責任を負います。
ただし、クライアントは自身の状態を管理できます。 クライアントは、ユーザー名とパスワード、ページ履歴など、適切と思われるデータを保存できます。 ステートレスであるための鍵は、クライアントからサーバーへのすべての要求が、要求を満たすために必要なすべてのデータを確実に持つようにすることです。
3.2. 無国籍の重要性
FieldingがRESTを定義するときにステートレス制約を含めた理由はたくさんあります。 何よりもまず、ステートレスシステムはスケーリングがはるかに簡単です。
複数のサーバーにデプロイされているアプリケーションについて考えてみます。 異なるサーバー間で複数のインスタンスを開始し、ユーザーはロードバランサーを介してそれらにアクセスします。 アプリケーションの各インスタンスが本当にステートレスである場合、どのクライアントもいつでも任意のインスタンスに接続できます。 これにより、ロードバランサーの作業がはるかに簡単になります。これは、リクエストの送信先を決定するときに、使用可能な任意のインスタンスを利用できるためです。 また、比較的簡単にいつでも新しいインスタンスを追加できます。
ただし、各インスタンスが対話するクライアントごとにセッション状態を維持している場合、ロードバランサーはリクエストをインスタンスに単純にルーティングすることはできません。 代わりに、セッションが確立されているクライアントが引き続き同じインスタンスを使用するようにする必要があります。
つまり、ロードバランサーはすべてのリクエストを調べ、アプリケーション自体をある程度理解している必要があります。 または、すべてのアプリケーションインスタンスがその状態を他のすべてのインスタンスと共有する共有コンテキストを作成することもできます。 これは通常、分散キャッシュまたはデータストアを使用して行われます。
これらのアプローチは両方とも、システムを複雑にします。 それらは新しい障害点を作成し、他の方法では存在しなかったコンポーネント間の結合も作成します。
スケーラビリティとは別に、ステートレス制約は、アプリケーションに他の望ましい品質をもたらします。 たとえば、すべてのリクエストを個別に監視および監視できるため、システムの可視性が向上します。
また、リカバリが容易な、より信頼性の高いシステムも入手できます。 1つのインスタンスが失敗すると、
4. セッションはRESTfulnessに違反しますか？
これで、質問に答える準備ができました。セッションはRESTfulnessに違反しますか？ 以前の2つの重要な情報を確認しましょう。
- セッションはサーバーに保存されます
- RESTful制約により、セッションはクライアントのみが保存する必要があります
この意味で、セッションは実際にRESTfulnessに違反します。 しかし、それは必ずしも悪いことではありません。 ソフトウェア開発におけるほとんどの決定と同様に、私たちはトレードオフを行っています。
ステートレス性を犠牲にすることで、より有意義なユーザーエクスペリエンスを実現しています。 電話でカートにアイテムを追加し、ラップトップでトランザクションを完了することができます。 Webサイトに一度ログインすると、独自のフィルターまたは設定に合わせてカスタマイズされたページのビューを取得できます。
5. 結論
この記事では、セッションが正確に何であるか、およびセッションがRESTfulnessに違反しているかどうかを確認しました。 サーバーに保存されるセッション状態は、RESTの主要な原則の1つに違反します。その状態は、クライアントによってのみ保存されます。
これにより、アプリケーションが元の定義ではRESTfulではなくなる可能性がありますが、トレードオフとして作成する価値があります。 アプリケーションはそれぞれ異なり、要件も異なります。 RESTの制約の一部を失うことで、さまざまなユーザーエクスペリエンスを実現できる可能性があります。
