サーバー側セッションはRESTに違反しますか？

Roy Fielding（HTTP仕様の主要著者の1人）によると、RESTについて議論する際に、彼の独創的な論文Architectural Stylesで次のように言及しています。

[E]クライアントからサーバーへの各リクエストには、リクエストを理解するために必要なすべての情報が含まれている必要があり、サーバーに保存されているコンテキストを利用することはできません。

「保存されたコンテキスト」とは、次のページのページ番号が何であるかなどのアプリケーションの状態と、データストア、イメージなどのリソースの状態を指します。

純粋な休憩（上記の論文に準拠する実装として定義されている）のほとんどの試みは、サーバー上のセッションデータの保存に依存しているために失敗しなければならない（永続的またはその他）と言っても過言ではありませんか？

セッションの概念は、特にWeb開発者にとっては一般的ですが、上記の定義に従ってRESTfulですか？

はい、セッション状態によってRESTfulアプリが非RESTfulになります。些細な例として、妹はWall Street Journalを購読しています。定期的に彼女はペイウォールの背後にある何かを読んで、WSJアカウントを持っていない友人に（WSJ経由ではなく自分のメールクライアント経由で）リンクを送信することにします。クリック、送信、失敗。明らかに、そのURLでの妹の経験は友人の経験とは異なります。

関連しますが、厳密にはトピックではありません：私は、ネット上での重要な研究努力をサポートするように設計されたアプリケーションの初期設計段階にいます（クエスト（思考：ステロイドとLSDのブックマーク）と呼ばれます）。クエストの所有者は自分のデータの特定のビューを他の人と共有したいが、このビューにはUIの状態（たとえば、どのデータがどのペインに表示されているか）とUIにアクセスするための適切なアクセス許可の組み合わせが必要表示されるデータ。受信者が目的のビューを取得するには、多くの保存状態が必要です。

私の現在のソリューションは、別のオブジェクトに表示するために必要なUI / ACL /何でも情報のすべてを保存し、用のURL（たぶんUUID）を返すことで、そのオブジェクト。ビューオブジェクトにアクセスすることは、それを所有するすべての人が同じ情報/経験を得るという意味でRESTfulであると考えることができると信じています。

サーバー側セッションはRESTに違反しますか？

彼らは間違いなくそうです！RESTを実装するときは、サーバー側のセッションが存在しないようにする必要があります。そうでない場合は、ハイブリッドRPC / RESTソリューションがあります。

クライアントは、新しい要求が行われるたびに、クライアントの認証に必要な情報を含む、要求の処理に必要なすべてのコンテキストをRESTfulサービスに送信する必要があります。サーバーは情報をキャッシュして自由に後続のリクエストを処理できますが、キャッシュされた情報がサーバー側のセッションに達してはなりません。言い換えると、リクエスト自体には、キャッシュされた状態がなくても処理されるのに十分な情報が含まれている必要があります。

おそらく、「セッションデータ」の意味に依存します。それは正確な用語ですか？

多くの場合、2者間の安全な通信には、サーバーが時間制限のある「アクセストークン」を生成（および保存）する必要があります。このアクセストークンは、私が「セッションデータ」と呼ぶものです-サーバー側に保存され、時間制限があり、1つのクライアントに関連付けられています（通常、彼のアクセス許可）。

この種の操作が非RESTfulとしてラベル付けされている場合、私は非常に驚くでしょう。OAuthは一例です。

私は専門家ではなく、ここではあまり自信がありません。私は自分の洞察を共有して、それらが役立つことを望んでいます。

RESTの最も重要なポイントは、リソースへのURIが常に同じリソースを指すことです。したがって、ユーザーはこのリソースへの参照を渡すことができ、誰もが同じように見えます。これは、Representational State Transfer（REST）と呼ばれます。サーバーが状態を保持し、同じURIに対して異なるリソースを配信する場合、これはもはや純粋なRESTではないと言えます。

セッションは、基本的にステートレスなRESTfulアプリケーションに状態を追加するために使用されます。正式には、これによりRESTfulアプリケーションはステートフルになりますが、サーバーが状態を保持することで、各リクエスト/レスポンスですべてのデータをやり取りする必要がなくなるため、生活が少し楽になります。

セッション、およびより一般的な状態では、これを回避できます。これにより、パフォーマンス（転送されるデータが少なくなる）およびセキュリティ（改ざんできるデータが少なくなる）でいくつかのプラスの利点があります。

したがって、RESTの定義の一部に公式に違反している一方で、セッション経由で状態を使用しない RESTfulアプリケーションを目にすることはめったにありません。

このステートメントが意味するのは、REST APIをホストするアプリケーションサーバーが、何らかの背後のメカニズムによって周囲の状態をリクエストに関連付けないことです。アプリケーションサーバーとデータベースサーバーの違いを考慮してください。RESTの制約は、アプリケーションサーバーがステートレスであることです。ただし、アプリケーションサーバーは、Authorizationヘッダーのユーザー/パスワードの組み合わせやUri自体など、要求の一部である情報に基づいて、リソース状態の要求をデータベースサーバーに委任できます。結局、RESTはクライアント/サーバーモデルに基づいています。