本物の REST Web サービスを構築している場合、セッションを持つことはできません。つまり、ユーザーが一度ログインすると、サーバーはセッションを記憶し、ユーザーはその後の呼び出しごとにそのセッションを使用します。REST サービスの場合、サーバーは「状態」を記憶しません。
各状態は、含まれる表現とそれが提供する遷移のセットによって完全に理解できます。遷移は、理解しやすいように一連のアクションに限定されます。
(出典: http://tech.groups.yahoo.com/group/rest-discuss/message/5841 )
サーバーへの各呼び出しには、ユーザーを認証するための一意の識別子が必要なため、これにより実際に作業が簡単になります。オプションには、ユーザー名とパスワードの組み合わせ、秘密鍵、およびユーザーを識別するためのその他の参照、あるいはその両方を送信することが含まれます。したがって、ユーザーが「ログイン」すると、クライアント側で詳細を記憶し (つまり、Web フォームの JavaScript で、またはアプリケーションによって、iPhone / Android のローカル ストレージに記憶されます)、呼び出しごとにそれらの詳細を送信します。残りの呼び出しを使用してログインの詳細を検証できますが、セッションは返されません。
したがって、疑似コードで答えるには:
- HTML: ユーザーのログイン。フォームが Javascript によってトラップされ、ユーザー名/パスワード (またはその他の秘密鍵) が JavaScript によって記憶されている、または
- iOS / Android: ユーザーがログインします。フォームはコードによってトラップされ、ローカル ストレージに記憶されます。
- [オプション] ユーザー名/パス/秘密鍵を「WhoAmI」Web サービスに送信します。有効な場合は、応答が返されます。有効でない場合は、エラーを送信します。これにより、すぐにフィードバックを得ることができます
- 他のすべての呼び出しで、ユーザー名/パス/秘密鍵も Web サービスに送信します。有効な場合は呼び出しを処理し、有効でない場合はエラーをスローします。
- (エラーが発生すると、ユーザーに新しい資格情報を要求します)。
PHP 側はシンプルです。すべての呼び出しは次のように表示されます。
- ユーザー名/パスワード/秘密鍵がない場合: 通話を拒否
- データベースでユーザー名/パスワード/秘密鍵を検索します。有効でない場合: 通話を拒否
- 有効な場合: 残りの通話を処理します - ユーザーの詳細が表示されます。
もちろん、認証を必要としないサービスを追加することもできます。これには登録が含まれる場合があります。