4.10. Handling Application State (アプリケーション状態の処理)

4.10. Handling Application State (アプリケーション状態の処理)

HTTP を使用するアプリケーションは, 状態をどのように処理するかを慎重に検討する必要があります。HTTP はしばしば "ステートレス" と表現されます。つまり, 各リクエストは独立しており, サーバーは以前のリクエストを記憶する必要がありません。ただし, 多くのアプリケーションは何らかの形式の状態管理を必要とします。

HTTP アプリケーションで状態を処理するにはいくつかの方法があります:

• クライアント側の状態: クライアントが状態を維持し, 各リクエストに含めます。これは最もスケーラブルなアプローチですが, クライアントが状態を管理する必要があります。

• サーバー側の状態: サーバーが各クライアントに関する状態を維持します。通常はセッショントークンによって識別されます。これはクライアントにとってより便利ですが, サーバーのスケーラビリティは低下します。

• リソース状態: 状態は HTTP メソッドを使用して取得および変更できるリソースとして表現されます。これは REST 原則とよく一致します。

アプリケーションは可能な限りステートレス設計を優先すべきです (SHOULD)。これらはよりスケーラブルで, 展開が容易になる傾向があるためです。状態が必要な場合, アプリケーションは次のことをすべきです (SHOULD):

• 状態がどのように維持および識別されるかを明確に指定する。

• セッション管理に Cookie [COOKIES] を使用することを検討しますが, そのセキュリティとプライバシーへの影響に注意してください。

• クライアント上で維持できる状態をサーバー上に保持することを避ける。

• 適切な場合はセッションではなく認証トークンを使用する。

• 中間者やキャッシュと連携するように状態管理を設計する。

アプリケーションは, 状態を維持するために TCP 接続の永続性などの機能に依存すべきではありません (SHOULD NOT)。接続は閉じられたり多重化されたりする可能性があるためです。