RESTful APIでCookieを使用する必要がありますか？

特に、ユーザーがWeb APIで許可/認証された操作を実行する方法に興味があります。

認証CookieはRESTの哲学と互換性がありますか？

理想的なReSTfulサービスでは、クライアント（ブラウザー内にない場合もあります）が1つの要求で必要なタスクを実行できます。そのために必要な完全な状態は、サーバーではなくクライアントによって保持されるためです。クライアントは状態を完全に制御できるため、それ自体で状態を作成でき（それが正当な場合）、APIと通信するだけで「完了」できます。

Cookieを要求すると、それが難しくなります。ブラウザ以外のクライアントの場合、Cookieの管理は、クエリパラメータ、プレーンなリクエストヘッダー、またはリクエスト本文と比較して非常に大きな不便です。一方、ブラウザでは、Cookieを使用すると、多くのことがより簡単になります。

だから、APIは、最初に見えるかもしれませんAuthorizationそれはおそらく、ブラウザ以外のクライアントはそれを置くことを好むだろうが、ブラウザベースのクライアントを簡素化し、合理化するための場所だから、それはかもしれない、それが必要とする認証データのヘッダもセッションクッキーをチェックサーバー側ログインの場合。ただし、通常のAuthorizationヘッダーが欠落している場合のみ。

別の例としては、通常多くのパラメーターセットを必要とする複雑な要求があります。非対話型クライアントは、すべてのデータを1つのリクエストに詰め込むのに問題はありませんが、HTMLフォームベースのインターフェイスでは、リクエストが複数のページ（「ウィザード」ページのようなもの）に分割され、ユーザーが表示されない場合があります以前の選択に基づいて適用できないオプションがあります。すべての中間ページはクライアント側のCookieに値を保存できるため、ユーザーが実際にリクエストを送信する最後のページのみがサーバー側の効果を持ちます。APIは、リクエスト本文で必要な属性を検索し、必要なパラメーターが存在しない場合はCookieの検索にフォールバックできます。

編集： REで以下の@Konradのコメントに：

比較するトークンは、特にどこかに保存しないとトークンを簡単に無効化できないため、実装が困難です。

えー...サーバー側でCookieを検証していますか？24時間後にCookieを破棄するようにブラウザに指示したからといって、Cookieが破棄されるわけではありません。このCookieは、高度な技術を持つユーザーが保存し、「期限切れ」になってからずっと後に再利用できます。

サーバー側にセッションデータを保存したくない場合は、トークン（Cookieなど）に保存する必要があります。自己完結型の認証トークンは、マカロンと呼ばれることもあります。 これがクライアントとサーバー間でどのように渡されるか（Cookie、追加ヘッダー、またはリクエストエンティティ自体）は、認証メカニズム自体から完全に独立しています。

はいおよびいいえ-使用方法に依存します。

クッキーは、クライアントで、クライアントのために、クライアントのクライアントの状態を維持するために使用され、クライアントによって安静になります。

サーバーの状態をCookieに保存している場合、基本的にはクライアントに負荷を移しているだけです-これは安静ではありません。

それでは、いくつかの例は何ですか？

安らかな：

• 認証の詳細または「ログイン中」のようなもの
• アプリケーションで最後に表示したページまたは場所など。

落ち着かない：

• セッション情報の保存

安らぎは、サーバーのステートレス性に起因します。クライアントはアプリケーションの状態を維持し、サーバーに送信して、サーバーがどこに行くかを決定できるように、サーバーがどこにいるかを伝えることができます。基本的に、セッション/状態には履歴データが必要であり、過去のリクエストに依存しているため、いわば、安らかなアプリケーションは理想的ではありません（ログイン画面がある場合、100％純粋な安らかなアプリケーションを持つことは現実的ではありません:)

Cookieを使用できます。RESTはそれらを許可します。

RESTでは、セッション情報をクライアント側に保存する必要がありますが、認証に関しては、セキュリティ上の理由から一部の情報をサーバー側に保持する必要があります。

私のブログ投稿の 1つから、RESTに関する認証データは範囲外と見なされるという一般的な合意があります。したがって、サーバーがこのセッションデータの一部を自分の側に保持することは問題ありません。