これを理解するのを手伝ってもらえますか？ 「一般的なREST間違い：セッションは無関係です。」
免責事項：私はRESTの考え方に慣れていないので、心を包み込もうとしています。
だから、私はこのページを読んでいる、 Common REST Mistakes 、そして私は無関係なセッションのセクションに完全に困惑していることに気付いた。ページは言う：
クライアントが「ログイン」または「接続を開始」する必要はないはずです。 HTTP認証はすべてのメッセージで自動的に行われます。クライアントアプリケーションは、サービスではなくリソースの消費者です。したがって、ログインするものは何もありません！ REST Webサービスでフライトを予約しているとしましょう。サービスへの新しい「セッション」接続は作成しません。むしろ、「作成者オブジェクト」に作成を依頼します新しい旅程：空白の入力を開始することができますが、Web上の別の場所にまったく別のコンポーネントを追加して、他の空白を入力できます。セッションがないため、クライアント間でセッション状態を移行する問題はありません。サーバーの「セッションアフィニティ」の（継続する負荷分散の問題がまだあります）.
さて、HTTP認証はすべてのメッセージで自動的に行われます-しかし、どうやってユーザー名/パスワードはすべてのリクエストで送信されますか？それは単に攻撃対象領域を増やすだけではありませんか？パズルの一部が欠けているように感じます。
RESTサービス、たとえば、/session、GETリクエストを受け入れます。GETリクエストでは、リクエストの一部としてユーザー名/パスワードを渡し、認証が成功した場合、セッショントークンを返します。その後、後続のリクエストとともに渡すことができますか？それはRESTの観点から意味がありますか、それともその点が欠けていますか？
RESTfulであるために、各HTTP要求は、受信者がそれを処理してHTTPのステートレスな性質と完全に調和するのに十分な情報をそれ自体で運ぶ必要があります。
さて、HTTP認証はすべてのメッセージで自動的に行われます-しかし、どうやって
はい、ユーザー名とパスワードはリクエストごとに送信されます。そのための一般的な方法は、基本アクセス認証およびダイジェストアクセス認証です。はい、盗聴者はユーザーの資格情報を取得できます。したがって、送受信されるすべてのデータをTransport Layer Security（TLS）を使用して暗号化します。
RESTサービス、たとえば/ session、GET要求を受け入れ、要求の一部としてユーザー名/パスワードを渡し、セッションを返すサービスがあると悪いでしょうか？認証が成功した場合、トークンはその後のリクエストと一緒に渡すことができますか？RESTの観点から意味がありますか、それともポイントがありませんか？
これはRESTfulではありませんが、状態を保持しますが、ユーザーにとっては便利なため非常に一般的です。ユーザーは毎回ログインする必要はありません。
「セッショントークン」で説明するものは、一般的にログインCookieと呼ばれます。たとえば、Yahoo！にログインしようとするとアカウントには、「2週間ログインし続ける」というチェックボックスがあります。これは本質的に（あなたの言葉で）「ログインに成功した場合、セッショントークンを2週間存続させます」と言っています。 Webブラウザーは、このようなログインCookie（および場合によっては他のCookie）を、ユーザーが要求するHTTPリクエストごとに送信します。
RESTサービスがすべてのHTTPリクエストに対して認証を要求することは珍しいことではありません。たとえば、Amazon S3では、すべてのリクエストにユーザー認証情報から実行される正確なリクエスト、この署名は、クライアント側で簡単に計算でき、サーバーで迅速に検証でき、それを傍受する攻撃者に限定的に使用されます（現在の時刻に基づいているため）。
多くの人はRESTプリンシパルを非常に明確に理解していません。セッショントークンを使用しても常にステートフルであるとは限りません。各リクエストでユーザー名/パスワードを送信する理由は認証のみであり、クライアントがデータを要求する許可を持っているかどうかを判断するためだけに（ログインプロセスによって生成された）トークンを送信する場合も同じです。ユーザー名/パスワードまたはセッショントークンのいずれかを使用して、RESTどのデータを表示するかを決定します！代わりに、データを聴覚のみに使用する必要があります（データを表示するか、データを表示しない）
あなたの場合、私はこれはREStyですと言いますが、REST APIでネイティブPHPセッションを使用しないようにして、決められた期間で期限切れになる独自のハッシュトークンの生成を開始してください！
いいえ、ポイントを見逃していません。 Googleの ClientLogin は、クライアントがHTTP 401応答を使用して「/ session」に移動するように指示されているという顕著な例外を除き、まさにこの方法で機能します。ただし、これはセッションを作成するのではなく、クライアントが平文で資格情報を渡さずに（一時的に）自分自身を認証し、サーバーが適切であると判断してこれらの一時的な資格情報の有効性を制御する方法を作成します。
さて、HTTP認証はすべてのメッセージで自動的に行われます-しかし、どうやって
「Authorization：」クライアントが送信するHTTPヘッダー。基本（プレーンテキスト）またはダイジェスト。
RESTサービス、たとえば/ sessionなど、GET要求を受け入れ、要求の一部としてユーザー名/パスワードを渡し、セッションを返すサービスは認証が成功した場合、トークンはその後のリクエストと一緒に渡すことができますか？RESTの観点から意味がありますか、それともポイントがありませんか？
セッションの全体的なアイデアは、サーバー側で状態を維持することにより、ステートレスプロトコル（HTTP）とダムクライアント（Webブラウザー）を使用してstatefulアプリケーションを作成することです。 REST原則は、 "「ハイパーメディアリンクで使用するユニバーサル構文を使用して、すべてのリソースを一意にアドレス指定できます」です。セッション変数はURIを介してアクセスできないものであり、真のRESTfulアプリケーションはクライアント側で状態を維持し、必要なすべての変数をHTTP（できればURI）で送信します。
例：ページネーションを使用した検索。フォームにURLがあります
http://server/search/urlencoded-search-terms/page_num
ブックマーク可能なURLと多くの共通点があります
クライアントセッションのライフタイムを制御したい場合、提案は大丈夫だと思います。 RESTfulアーキテクチャは、ステートレスアプリケーションの開発を促進すると思います。 @ 2penceが書いたように「各HTTPリクエストは、受信者がHTTPのステートレスな性質と完全に調和するように処理するために十分な情報をそれ自身で運ぶ必要があります」 。
ただし、常にそうであるとは限らず、アプリケーションは、クライアントがログインまたはログアウトするタイミングを通知し、この情報に基づいてロックやライセンスなどのリソースを維持する必要がある場合があります。そのようなケースの例については、私のフォローアップ question をご覧ください。