2011-10-12 8 views
7

私はクライアントセッションの永続性をサポートするべき小さなRESTサービスを開発しています。 RESTのおかげでわかったように、クライアントデータをサーバーに保存することはできません。データはクライアント側に保存する必要があり、クライアントの要求は自立していなければなりません。だから...クライアントセッションをどのように保存することができますか?インターネット上での検索私はこれを実現する方法をいくつか見つけました。たとえば、クライアントのID(nickなど)を含む暗号化されたトークンをクライアントに送信します(トークン= AES(id、secretKey)など)。秘密鍵でサーバ上のトークンを解読するたびにユーザに権限を与えます。誰も助言することはできますか?たぶん、同じ機能を実行するもう一つの良い方法があります。どの暗号アルゴリズムがこれに適しているでしょうか?ありがとう。RESTサービスのセッション

+0

これらの永続化クライアントセッションで何を達成しようとしていますか?それは単に認証プロセスのパフォーマンス最適化ですか? –

答えて

8

あなたが言及:RESTの我々は サーバー上の任意のクライアントデータを保存することはできませんので、あなたが知っているように

を、データをクライアント側に保存されている必要があり、クライアントの要求が 自己十分なものでなければなりません。

RESTでは、クライアントデータをサーバーに保存できないとは言いません。 アプリケーションの状態を保存してはならないと言っています。この状態は「このクライアントが何をしようとしているのか」と考えることができます。

認証されたユーザーの概念を主に考えているのであれば、標準のログインCookieはうまく動作し、「unRESTful」ではありません。

+0

私が見つけた唯一の論理的な説明。それが正しいことを願って – GorillaApe

2

この質問に対する回答はすべて、最初に「セッション」概念が必要なのはなぜですか?

クライアントが資格情報のセットを表すCookieを確実に渡す必要がある場合は、代わりに各リクエストでHTTPS認証ヘッダーとしてクライアントを渡すことを検討してください。

(クライアントの要求が特定のサーバーに送信されるようにするために)いくつかのスティッキールーティングルールが必要な場合は、この機会を使用して、アーキテクチャ上のストレートジャケットを取り除くことが最も簡単です将来のスケーラビリティの可能性代わりに、あなたのサーバーを任意に選択してください。

特定のノードにルーティングする必要がある場合は、クライアントが特定の「スイムレーン」をハッシュまたはシャードするのに使用できる十分な識別データをクライアントに渡すようにしてください。たとえば、ユーザー名に基づいて物事を分割することができます。