免責事項: 私は REST の考え方に不慣れであり、それを理解しようとしているところです。
それで、私はこのページを読んでいます、よくあるRESTの間違い、そしてセッションが無関係であるというセクションに完全に困惑していることに気づきました。ページには次のように書かれています:
クライアントが「ログイン」したり「接続を開始」したりする必要はありません。HTTP 認証は、すべてのメッセージで自動的に行われます。クライアント アプリケーションは、サービスではなくリソースの消費者です。したがって、ログインするものは何もありません。REST Web サービスでフライトを予約しているとします。サービスへの新しい「セッション」接続は作成しません。代わりに、「旅程作成オブジェクト」に新しい旅程を作成するように依頼します。空白を埋め始めてから、Web 上の他の場所にあるまったく異なるコンポーネントを取得して、他の空白を埋めることができます。セッションがないため、クライアント間でセッション状態を移行する問題はありません。サーバーでの「セッション アフィニティ」の問題もありません (ただし、引き続き負荷分散の問題が残っています)。
わかりました。HTTP 認証がすべてのメッセージで自動的に行われるのはわかりますが、どのように行われるのでしょうか。ユーザー名とパスワードはすべてのリクエストで送信されるのでしょうか。それだけでは攻撃対象領域が拡大するだけではないでしょうか。パズルの一部が欠けているような気がします。
たとえば、GET リクエストを受け入れ、ユーザー名とパスワードをリクエストの一部として渡し、認証が成功した場合にセッション トークンを返し、それを後続のリクエストとともに渡すことができるような REST サービスがあるとしたら、/sessionそれは悪いことでしょうか。これは REST の観点から見て理にかなっていますか、それとも要点を外しているのでしょうか。
ベストアンサー1
RESTful であるためには、各 HTTP リクエストは、HTTP のステートレスな性質と完全に調和するように、受信者が処理するのに十分な情報をそれ自体で運ぶ必要があります。
すべてのメッセージで HTTP 認証が自動的に実行されることはわかりましたが、どのように行われるのでしょうか?
はい、ユーザー名とパスワードはリクエストごとに送信されます。一般的な方法は次のとおりです。基本アクセス認証そしてダイジェストアクセス認証そして、盗聴者はユーザーの認証情報を取得することができます。そのため、送受信されるすべてのデータを暗号化します。トランスポート層セキュリティ (TLS)。
たとえば、/session のような REST サービスが GET リクエストを受け入れ、ユーザー名とパスワードをリクエストの一部として渡し、認証が成功した場合はセッション トークンを返し、それを後続のリクエストと一緒に渡すのは悪いことでしょうか。これは REST の観点からは理にかなっていますか、それとも要点が抜けているでしょうか。
これはRESTful状態を保持するためですが、ユーザーにとって便利であり、ユーザーが毎回ログインする必要がないため、非常に一般的です。
「セッショントークン」で説明するものは、一般的にログインクッキーたとえば、Yahoo! アカウントにログインしようとすると、「2 週間ログイン状態を維持する」というチェックボックスが表示されます。これは基本的に (あなたの言葉で言えば)、「ログインに成功したら、セッション トークンを 2 週間有効にしておく」という意味です。Web ブラウザーは、このようなログイン クッキー (および場合によってはその他のクッキー) を、ユーザーが要求する各 HTTP リクエストとともに送信します。