セッションは本当にRESTfulnessに違反しますか? 質問する

まず第一に、REST は宗教ではないので、そのようにアプローチすべきではありません。RESTful サービスには利点がありますが、アプリケーションにとって意味がある限りにおいてのみ、REST の原則に従うべきです。

とはいえ、認証とクライアント側の状態は REST の原則に違反しません。REST では状態遷移がステートレスであることが求められますが、これはサーバー自体のことです。REST の根底にあるのはドキュメントです。ステートレスの背後にある考え方は、サーバーがステートレスであり、クライアントがステートレスではないということです。同一のリクエスト (同じヘッダー、Cookie、URI など) を発行するクライアントは、アプリケーション内の同じ場所に移動する必要があります。Web サイトがユーザーの現在の場所を保存し、このサーバー側のナビゲーション変数を更新することでナビゲーションを管理する場合、REST に違反することになります。同一のリクエスト情報を持つ別のクライアントは、サーバー側の状態に応じて異なる場所に移動します。

Google の Web サービスは、RESTful システムの素晴らしい例です。これらのサービスでは、すべてのリクエストでユーザーの認証キーを含む認証ヘッダーを渡す必要があります。サーバーが認証キーの状態を追跡しているため、これは REST の原則に少し違反しています。このキーの状態は維持する必要があり、何らかの有効期限が設定されており、その期限を過ぎるとアクセスが許可されなくなります。ただし、投稿の冒頭で述べたように、アプリケーションが実際に機能するには犠牲を払う必要があります。とはいえ、認証トークンは、すべてのクライアントが有効な期間中はアクセスを許可し続けることができる方法で保存する必要があります。あるサーバーが認証キーの状態を管理しているため、別の負荷分散サーバーがそのキーに基づいてリクエストの処理を引き継ぐことができない場合は、REST の原則に違反し始めています。Google のサービスでは、いつでも、スマートフォンで使用していた認証トークンを負荷分散サーバー A に対して取得し、デスクトップから負荷分散サーバー B にアクセスしても、システムにアクセスでき、リクエストが同一であれば同じリソースにリダイレクトされます。

結局のところ、REST プロパティをできるだけ多く保持するためには、認証トークンが何らかのバックアップ ストア (データベース、キャッシュなど) に対して検証されていることを確認する必要があります。

ここまでの内容が理解できたでしょうか。制約セクションの表現的状態転送に関するウィキペディアの記事まだ読んでいないのであれば、ぜひ読んでみてください。REST の信条が実際に何を主張しているのか、そしてその理由については特に啓発されます。