説明が必要です。私は REST について読んでいて、RESTful アプリケーションを構築しています。Wikipedia によると、REST 自体はRepresentational State Transferと定義されています。そのため、誰もが吐き出し続けるこのステートレスな意味不明な言葉が理解できません。
ウィキペディアより:
特定の時点で、クライアントはアプリケーション状態間の遷移中または「休止中」のいずれかになります。休止状態のクライアントはユーザーと対話できますが、負荷は発生せず、サーバー セットまたはネットワーク上のクライアントごとのストレージは消費されません。
セッション/アプリケーション レベルのデータ ストアを使用しないように言っているだけでしょうか?
REST の目標の 1 つは、URI アクセスを一貫性のあるものにし、利用可能にすることであることは理解しています。たとえば、ページング要求を投稿内に隠すのではなく、要求のページ番号を GET URI の一部にします。私には理にかなっています。しかし、クライアントごとのデータ(セッション データ) をサーバー側に保存してはならないというのは、やりすぎのように思えます。
メッセージのキューがあり、ユーザーがメッセージを読みたいが、読んでいる間、セッション中は特定の送信者からのメッセージをブロックしたい場合はどうでしょうか? これをサーバー側の場所に保存し、ユーザーがブロックしていないメッセージ (またはメッセージ ID) のみをサーバーが送信するようにすると合理的ではないでしょうか?
新しいメッセージ リストを要求するたびに、ブロックするメッセージ送信者のリスト全体を本当に送信する必要がありますか? そもそも、自分に関連するメッセージ リストは、公開されているリソースではないはずです。
もう一度言いますが、ただこれを理解しようとしているだけです。誰か明確にしてください。
アップデート：
スタックオーバーフローの質問を見つけましたが、その答えは完全には理解できませんでした。RESTで状態を管理する方法これは、重要なクライアント状態がすべてのリクエストで転送される必要があることを示しています... うーん... オーバーヘッドがかなりあるように思えます... これは正しいですか??
ベストアンサー1
基本的な説明は次のとおりです。
サーバー上にクライアント セッション状態がありません。
ステートレスとは、サーバー側でクライアント セッションに関する状態を一切保存しないことを意味します。
クライアントセッションはクライアントに保存されます。サーバーがステートレスであるということは、すべてのサーバーがいつでも任意のクライアントにサービスを提供できることを意味します。セッション アフィニティやスティッキー セッションはありません。関連するセッション情報はクライアントに保存され、必要に応じてサーバーに渡されます。
これは、Web サーバーが通信する他のサービスが、ショッピング カートなどのビジネス オブジェクトに関する状態を維持することを妨げるものではありませんが、クライアントの現在のアプリケーション/セッション状態に関する状態を維持することは妨げません。
クライアントのアプリケーション状態はサーバー上に保存されるべきではなく、クライアントからそれを必要とするすべての場所に渡されるべきです。
RESTのST ( State Transfer)はここから来ています。サーバーに状態を保存させるのではなく、状態を転送します。これは、数百万の同時ユーザーに拡張できる唯一の方法です。何百万ものセッションは数百万のセッションであるからという理由だけで。
セッション管理の負荷はすべてのクライアント間で分散され、クライアントはセッション状態を保存し、サーバーはステートレスな方法で何桁も多数のクライアントにサービスを提供できます。
同時ユーザーが数万人程度しか必要ないと予想されるサービスであっても、サービスをステートレスにする必要があります。数万人は数万人であり、それに伴う時間とスペースのコストが発生します。
ステートレスは、HTTP プロトコルと Web 全般が動作するように設計された方法であり、全体的にシンプルな実装であり、一連のセッション状態を維持するために一連のサーバー側ロジックを使用する代わりに、単一のコード パスを使用します。
非常に基本的な実装原則がいくつかあります。
これらは実装ではなく原則であり、これらの原則を満たす方法は異なる場合があります。
要約すると、5つの基本原則は：
- すべての「もの」にIDを付与する
- 物事を結びつける
- 標準的な方法を使用する
- 複数の表現を持つリソース
- ステートレスに通信する
RESTには認証や認可に関する規定はない論文。
RESTful なリクエストを認証することとそうでないリクエストを認証することに違いはありません。認証は RESTful の議論とは無関係です。
特定の要件に合わせてステートレス アプリケーションを作成する方法を説明するのは、StackOverflow では範囲が広すぎます。
REST に関連する認証と承認の実装はさらに広範囲にわたるため、実装のさまざまなアプローチは一般にインターネット上で詳細に説明されています。
これに関するヘルプや情報を求めるコメントには、「不要」というフラグが付けられます。