これを理解するのを手伝ってくれませんか？「一般的なRESTの間違い：セッションは無関係です」

免責事項：私はRESTの考え方に慣れていないので、RESTスクールに集中しようとしています。

したがって、私はこのページ、「一般的なRESTの間違い」を読んでおり、関連性のないセッションのセクションに完全に困惑していることがわかりました。これはページが言うことです：

クライアントが「ログイン」または「接続を開始」する必要はないはずです。HTTP認証はすべてのメッセージで自動的に行われます。クライアントアプリケーションは、サービスではなくリソースのコンシューマです。したがって、ログインする必要はありません。REST Webサービスでフライトを予約しているとしましょう。サービスへの新しい「セッション」接続を作成しません。むしろ、「旅程作成者オブジェクト」に新しい旅程を作成するように依頼します。空白を埋め始めることができますが、その後、Webの他の場所にまったく異なるコンポーネントを取得して、他の空白を埋めることができます。セッションがないため、クライアント間でセッション状態を移行する問題はありません。「セッションアフィニティ」の問題もありません

さて、HTTP認証はすべてのメッセージで自動的に行われることになりますが、どうやって？ユーザー名/パスワードはすべてのリクエストで送信されますか？それだけで攻撃の表面積が増えるのではないですか？パズルの一部が欠けているような気がします。

たとえば、/sessionGETリクエストを受け入れ、リクエストの一部としてユーザー名/パスワードを渡し、認証が成功した場合にセッショントークンを返すRESTサービスがあると悪いでしょう。後続のリクエストと一緒に渡されましたか？それはRESTの観点からは理にかなっていますか、それともポイントが不足していますか？

RESTfulであるためには、各HTTPリクエストは、受信者がHTTPのステートレスな性質と完全に調和するように処理するために、それ自体で十分な情報を運ぶ必要があります。

さて、HTTP認証はすべてのメッセージで自動的に行われることになりますが、どうやって？

はい、ユーザー名とパスワードはリクエストごとに送信されます。これを行う一般的な方法は、基本アクセス認証とダイジェストアクセス認証です。そして、はい、盗聴者はユーザーの資格情報を取得できます。したがって、トランスポート層セキュリティ（TLS）を使用して送受信されるすべてのデータを暗号化します。

GETリクエストを受け入れ、リクエストの一部としてユーザー名/パスワードを渡し、認証が成功した場合にセッショントークンを返すRESTサービス、たとえば/ sessionがあると悪いのではないでしょうか。その後のリクエストと一緒に渡されますか？それはRESTの観点からは理にかなっていますか、それともポイントが不足していますか？

これはRESTfulではありません状態をため、ユーザーにとって便利であるため、非常に一般的です。ユーザーは毎回ログインする必要はありません。

「セッショントークン」で記述したものは、通常、ログインCookieと呼ばれます。たとえば、Yahoo！にログインしようとすると、アカウントには、「2週間ログインしたままにする」というチェックボックスがあります。これは基本的に（あなたの言葉で）「ログインに成功した場合、セッショントークンを2週間保持する」と言っています。Webブラウザーは、ユーザーが要求するHTTP要求ごとに、そのようなログインCookie（および場合によってはその他）を送信します。

RESTサービスがすべてのHTTPリクエストに対して認証を要求することは珍しくありません。たとえば、Amazon S3では、すべてのリクエストに、ユーザーの認証情報、実行する正確なリクエスト、および現在の時刻から派生した署名が必要です。このシグネチャは、クライアント側で簡単に計算でき、サーバーですばやく検証でき、（現在の時刻に基づいているため）傍受する攻撃者に限定的に使用されます。

多くの人はRESTプリンシパルをあまり明確に理解していません。セッショントークンを使用しても、常にステートフルであるとは限りません。各リクエストでユーザー名/パスワードを送信する理由は、認証のためだけであり、トークンを送信するためと同じです（ログインによって生成されます）プロセス）クライアントにデータをリクエストする権限があるかどうかを判断するためだけに、ユーザー名/パスワードまたはセッショントークンのいずれかを使用して、表示するデータを決定する場合にのみRESTの違反に違反します！代わりに、それらを認証のためにのみ使用する必要があります（データを表示するか、またはデータを表示しないため）

あなたのケースでは私はYESと言っていますが、これはRESTyですが、REST APIでネイティブのphpセッションを使用しないようにして、決められた期間で期限切れになる独自のハッシュトークンの生成を開始してください！

いいえ、要点を見逃しません。GoogleのClientLoginは、クライアントがHTTP 401応答を使用して「/セッション」に移動するように指示されていることを除いて、まったく同じように機能します。ただし、これによってセッションが作成されるわけではありません。クライアントが（一時的に）資格情報を平文で渡さずに自分自身を認証し、サーバーがこれらの一時的な資格情報の妥当性を適切に制御する方法を作成するだけです。

さて、HTTP認証はすべてのメッセージで自動的に行われることになりますが、どうやって？

「Authorization：」クライアントが送信したHTTPヘッダー。基本（プレーンテキスト）またはダイジェスト。

GETリクエストを受け入れ、リクエストの一部としてユーザー名/パスワードを渡し、認証が成功した場合にセッショントークンを返すRESTサービス、たとえば/ sessionがあると悪いのではないでしょうか。その後のリクエストと一緒に渡されますか？それはRESTの観点からは理にかなっていますか、それともポイントが不足していますか？

セッションの全体的な考え方は、サーバー側の状態を維持することにより、ステートレスプロトコル（HTTP）とダムクライアント（Webブラウザ）を使用してステートフルアプリケーションを作成することです。RESTの原則の1つは、「ハイパーメディアリンクで使用するためのユニバーサル構文を使用して、すべてのリソースを一意にアドレス指定できる」です。セッション変数は、URIを介してアクセスできないものです。真にRESTfulなアプリケーションはクライアント側で状態を維持し、必要なすべての変数をHTTP経由で、できればURIで送信します。

例：ページネーション付きの検索。フォームにURLがあります

http://server/search/urlencoded-search-terms/page_num

ブックマーク可能なURLと多くの共通点があります

クライアントセッションのライフタイムを制御したい場合は、提案は問題ないと思います。RESTfulアーキテクチャーは、ステートレスアプリケーションの開発を促進すると思います。@ 2penceが書いたように、「各HTTPリクエストは、受信者がHTTPのステートレスな性質と完全に調和するように処理するために、それ自体で十分な情報を運ぶ必要があります」。

ただし、常にそうであるとは限りません。アプリケーションは、クライアントのログインまたはログアウトのタイミングを通知し、この情報に基づいてロックやライセンスなどのリソースを維持する必要がある場合があります。そのような場合の例については、私のフォローアップの質問を参照してください。