セッションは本当にRESTfulnessに違反していますか？

RESTful APIでのセッションの使用は本当にRESTfulnessに違反していますか？私は多くの意見がどちらの方向にも進んでいるのを見てきましたが、セッションがRESTなしであるとは思いません。私の視点から：

• 認証はRESTfulnessで禁止されていません（そうでなければRESTfulサービスではほとんど使用されません）
• 認証は、リクエストで認証トークンを送信することで行われ、通常はヘッダー
• この認証トークンは何らかの方法で取得する必要があり、取り消すことができます。その場合、更新する必要があります
• 認証トークンはサーバーによって検証される必要があります（そうでなければ、認証ではありません）

では、セッションはこれにどのように違反しますか？

• クライアント側、セッションはcookieを使用して実現されます
• Cookieは単なる追加のHTTPヘッダーです
• セッションCookieはいつでも取得して取り消すことができます
• セッションCookieは、必要に応じて無限の寿命を持つことができます
• セッションID（認証トークン）はサーバー側で検証されます

そのため、クライアントにとって、セッションCookieは、他の独自のヘッダーのCookie代わりにヘッダーを使用することを除いて、他のHTTPヘッダーベースの認証メカニズムとまったく同じAuthorizationです。サーバー側のCookie値にセッションがアタッチされていない場合、なぜ違いが生じるのでしょうか？サーバーが RESTfulに動作する限り、サーバー側の実装はクライアントに関係する必要はありません。そのため、Cookie自体はAPIをRESTlessにすべきではなく、セッションは単にクライアントへのCookieです。

私の仮定は間違っていますか？セッションCookieをRESTレスにするものは何ですか？

まず、いくつかの用語を定義しましょう：

• RESTful：

  このセクションで説明するREST制約に準拠するアプリケーションを「RESTful」として特徴付けることができます。[15] サービスが必要な制約に違反している場合、RESTfulとは見なされません。

  ウィキペディアによると。

• ステートレス制約：

  次に、クライアントとサーバーの相互作用に制約を追加します。セクション3.4.3（図5-3）のクライアントステートレスサーバー（CSS）スタイルのように、通信は本質的にステートレスである必要があります。サーバーには、リクエストを理解するために必要なすべての情報が含まれている必要があり、サーバーに保存されているコンテキストを利用することはできません。したがって、セッション状態は完全にクライアントで保持されます。

  フィールディングの論文。

したがって、サーバー側のセッションはRESTのステートレスな制約に違反しているため、RESTfulにも違反しています。

そのため、クライアントにとって、セッションCookieは、Authorizationまたはその他の独自のヘッダーの代わりにCookieヘッダーを使用することを除いて、他のHTTPヘッダーベースの認証メカニズムとまったく同じです。

セッションCookieを使用すると、クライアントの状態をサーバーに保存するため、リクエストにはコンテキストが含まれます。ロードバランサーと別のサービスインスタンスをシステムに追加してみましょう。この場合、サービスインスタンス間でセッションを共有する必要があります。そのようなシステムを維持および拡張することは難しいので、スケーリングがひどいです...

私の意見では、クッキーには何の問題もありません。Cookieテクノロジーはクライアント側の保存メカニズムであり、保存されたデータはすべてのリクエストによってCookieヘッダーに自動的に添付されます。そのようなテクノロジーに問題があるREST制約については知りません。したがって、テクノロジー自体には問題はありません。問題はその使用法です。フィールディングは、 HTTP Cookieが悪いと考える理由についての小節を書きました。

私の視点から：

• 認証はRESTfulnessで禁止されていません（そうでなければRESTfulサービスではほとんど使用されません）
• 認証は、リクエストで認証トークンを送信することで行われ、通常はヘッダー
• この認証トークンは何らかの方法で取得する必要があり、取り消すことができます。その場合、更新する必要があります
• 認証トークンはサーバーによって検証される必要があります（そうでなければ、認証ではありません）

あなたの視点はかなり堅実でした。唯一の問題は、サーバー上で認証トークンを作成するという概念にありました。その部分は必要ありません。必要なのは、ユーザー名とパスワードをクライアントに保存し、すべてのリクエストで送信することです。HTTP基本認証と暗号化された接続以外にこれを行う必要はありません。

• 図1.-信頼できるクライアントによるステートレス認証

すべてのリクエストを認証する必要があるため、処理を高速化するためにサーバー側にメモリ内の認証キャッシュが必要になる可能性があります。

これはあなたが書いた信頼できるクライアントでかなりうまく動作しますが、サードパーティのクライアントはどうですか？ユーザー名とパスワード、およびユーザーのすべての権限を持つことはできません。そのため、サードパーティのクライアントが特定のユーザーに対して持つことができる権限を個別に保存する必要があります。そのため、クライアント開発者はサードパーティのクライアントを登録して一意のAPIキーを取得でき、ユーザーはサードパーティのクライアントに権限の一部へのアクセスを許可できます。名前やメールアドレスを読んだり、友達をリストしたりするのと同じように...サードパーティのクライアントを許可した後、サーバーはアクセストークンを生成します。これらのアクセストークンは、次のように、サードパーティのクライアントがユーザーによって付与された権限にアクセスするために使用できます。

• 図2.-サードパーティのクライアントによるステートレス認証

したがって、サードパーティのクライアントは、信頼できるクライアントから（またはユーザーから直接）アクセストークンを取得できます。その後、APIキーとアクセストークンを使用して有効なリクエストを送信できます。これは、最も基本的なサードパーティの認証メカニズムです。実装の詳細については、OAuthなどのサードパーティの認証システムのドキュメントをご覧ください。もちろん、これはより複雑で安全です。たとえば、サーバー側ですべてのリクエストの詳細に署名し、リクエストとともに署名を送信できます。実際の解決策は、アプリケーションのニーズによって異なります。

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

つまり、認証とクライアント側の状態はRESTの原則に違反していません。RESTは状態遷移がステートレスであることを要求しますが、これはサーバー自体を参照しています。基本的に、RESTはすべてドキュメントに関するものです。ステートレスの背後にある考え方は、サーバーはクライアントではなくステートレスであるということです。同じ要求（同じヘッダー、Cookie、URIなど）を発行するクライアントは、アプリケーションの同じ場所に移動する必要があります。Webサイトがユーザーの現在の場所と、このサーバー側のナビゲーション変数を更新することによって管理されたナビゲーションを格納した場合、RESTに違反します。同じ要求情報を持つ別のクライアントは、サーバー側の状態に応じて別の場所に移動されます。

GoogleのWebサービスは、RESTfulシステムの素晴らしい例です。ユーザーの認証キーを含む認証ヘッダーが要求ごとに渡される必要があります。サーバーが認証キーの状態を追跡しているため、これはRESTの原則に少し違反しています。このキーの状態は維持する必要があり、ある種の有効期限の日時があり、その後はアクセスを許可しなくなります。ただし、投稿の冒頭で述べたように、アプリケーションを実際に機能させるには犠牲を払わなければなりません。とはいえ、認証トークンは、すべての可能なクライアントが有効な時間の間アクセスを許可し続けることができるような方法で保存する必要があります。あるサーバーが認証キーの状態を管理していて、別の負荷分散サーバーがそのキーに基づいて要求を満たすことができない場合、RESTの原則に本当に違反し始めました。Googleのサービスにより、携帯電話で使用していた認証トークンをいつでもロードバランスサーバーAに対して取得し、デスクトップからロードバランスサーバーBにアクセスでき、システムにアクセスでき、同じリソースにリダイレクトされます要求は同じでした。

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

それがすべて理にかなっているといいのですが。また、チェックアウトする必要があり制約セクションののRepresentational State譲渡に関するWikipediaの記事をお持ちでない場合。RESTの信条が実際に主張していることとその理由に関しては、特に啓蒙的です。

Cookieは認証用ではありません。なぜ車輪を再発明するのですか？HTTPには、適切に設計された認証メカニズムがあります。Cookieを使用する場合、トランスポートプロトコルとしてのみHTTPを使用することになり、たとえば、ユーザーに間違った認証を提供したことをユーザーに通知するために、独自のシグナリングシステムを作成する必要があります（HTTP 401を使用すると、おそらく、Www-AuthenticateHTTP仕様に必要なクライアントへの供給:)）。また、これはSet-Cookieクライアントに対する推奨事項にすぎません。Authorizationヘッダーはすべてのリクエストで自動的に送信されますが、その内容は保存される場合と保存されない場合があります（Cookieが無効になっている場合など）。

もう1つのポイントは、認証Cookieを取得するには、おそらくどこかで資格情報を最初に提供する必要があるということです。もしそうなら、それはRESTlessではないでしょうか？簡単な例：

• GET /aクッキーなしでやってみる
• どういうわけか認可リクエストを受け取ります
• あなたはどういうわけか行くと承認します POST /auth
• あなたが得る Set-Cookie
• あなたは試すGET /a とクッキー。しかしGET /a、この場合はべき等に振る舞いますか？

これを要約すると、あるリソースにアクセスして認証する必要がある場合、他の場所ではなく、同じリソースで認証する必要があると思います。

実際、RESTfulnessはRESOURCESにのみ適用され、Universal Resource Identifierで示されています。したがって、RESTに関してヘッダーやCookieなどについて話すことさえ、適切ではありません。RESTは、HTTPを介して日常的に行われていますが、どのプロトコルでも機能します。

主な決定要素は次のとおりです。URIであるREST呼び出しを送信すると、呼び出しがサーバーに正常に送信されると、遷移が実行されていないと仮定して（PUT、POST、DELETE）、そのURIは同じコンテンツを返します。 ？このテストでは、エラーまたは認証リクエストが返されないようにします。その場合、リクエストはまだサーバーに届いていないため、指定されたURIに対応するドキュメントを返すサーブレットまたはアプリケーションを意味します。

同様に、POSTまたはPUTの場合、特定のURI /ペイロードを送信できます。メッセージを送信する回数に関係なく、常に同じデータを更新するため、後続のGETは一貫した結果を返しますか？

RESTはアプリケーションデータに関するものであり、データを転送するために必要な低レベルの情報に関するものではありません。

次のブログ投稿で、Roy FieldingがRESTのアイデア全体のすばらしい要約を提供しました。

http://groups.yahoo.com/neo/groups/rest-discuss/conversations/topics/5841

「RESTfulシステムは、ある定常状態から次の定常状態へと進み、そのような各定常状態は、潜在的な開始状態と潜在的な終了状態の両方です。つまり、RESTfulシステムは、単純な一連のコンポーネントに従う未知の数のコンポーネントです。常にREST状態であるか、RESTful状態から別のRESTful状態に遷移するようなルール。各状態は、その状態に含まれる表現と、それが提供する一連の遷移によって完全に理解でき、遷移は均一に制限されます。システムは複雑な状態図である場合がありますが、各ユーザーエージェントは一度に1つの状態（現在の定常状態）しか表示できないため、各状態は単純であり、個別に分析できます。ユーザー、OTOHはいつでも独自のトランジションを作成できます（例：URLの入力、ブックマークの選択、エディタなどを開きます。」

認証の問題に行くと、情報がURIとPOSTペイロードの一部でない限り、それがCookieとヘッダーのどちらを介して行われても、RESTとはまったく関係がありません。したがって、ステートレスであることに関しては、アプリケーションデータのみについて説明しています。

たとえば、ユーザーがGUI画面にデータを入力すると、クライアントは入力されたフィールド、入力されなかったフィールド、欠落している必須フィールドなどを追跡します。これはすべてクライアントコンテキストであり、送信または追跡しないでください。サーバーによって。サーバーに送信されるのは、IDENTIFIEDリソースで（URIによって）変更する必要があるフィールドの完全なセットです。これにより、そのリソースでRESTful状態から別の状態への遷移が発生します。

したがって、クライアントはユーザーが何をしているかを追跡し、論理的に完全な状態遷移のみをサーバーに送信します。

HTTPトランザクション、基本アクセス認証は、RBACには適していません。基本アクセス認証は、暗号化されたusername：passwordを毎回使用して識別しますが、RBACで必要なのは、ユーザーが特定の通話に使用する役割です。RBACは、ユーザー名ではなく、ロールに対する権限を検証しません。

次のようにトリックして連結することもできます：usernameRole：password。これは悪い習慣です。また、ユーザーがより多くのロールを持っている場合、認証エンジンは連結ですべてのロールをテストする必要があり、そのたびにすべての呼び出しを繰り返す必要があります。これは、RBACの最大の技術的利点の1つ、つまり非常に迅速な承認テストを破壊します。

そのため、基本的なアクセス認証を使用してその問題を解決することはできません。

この問題を解決するには、セッションを維持する必要があります。これは、一部の回答によれば、RESTと矛盾しているようです。

それが、RESTを宗教として扱うべきではないという答えについて私が気に入っている点です。複雑なビジネスケース、たとえばヘルスケアでは、RBACは絶対的に一般的で必要です。また、RESTツールの設計者はすべてRESTを宗教として扱うため、RESTの使用が許可されないのは残念です。

私にとって、HTTPを介してセッションを維持する方法は多くありません。sessionIdを持つCookie、またはsessionIdを持つヘッダーを使用できます。

誰かが別のアイデアを持っているなら、私はそれを聞いてうれしいです。

トークンには、その中にエンコードされた必要なすべての情報を含める必要があると思います。これにより、トークンを検証して情報をデコードすることで認証が行われ ますhttps://www.oauth.com/oauth2-servers/access-tokens/self-encoded-access-tokens/

1. セッションはRESTレスではありません
2. http専用のRESTサービスですか、それとも間違っているのですか？Cookieベースのセッションは、独自の（！）httpベースのサービスにのみ使用する必要があります！（たとえば、モバイル/コンソール/デスクトップ/などからのCookieを処理することは問題になる可能性があります。）
3. サードパーティの開発者にRESTfulサービスを提供し、Cookieベースのセッションを使用しない場合は、代わりにトークンを使用してセキュリティの問題を回避してください。