REST - 許可の確認に使用する動詞

Question

要求内でAuthorizationヘッダーを受信して​​いる他のパブリックサービスによって内部的に照会される承認サービスを設計しています。

このサービスは認証（公開鍵（user_id）と秘密鍵のペア）を処理し、そのタスクは秘密鍵を知る唯一のサービスである署名（HMAC）を再生成することです。私はこれをサーバーリソースとして識別します。それから私は、ユーザーのない無許可の資源が存在しないと考えたので、私は、このベースでURI終わった：

/user/:user_id/authorization 

私は、新しいユーザーが作成されたときに作成し、承認を処理するためにCRUD操作を設計した、更新要求されるたびに、ユーザーが削除されたときに読み取りと削除を行います。

注：Userエンティティは別のサービスによって処理されます。私はこのURIを使用して公開鍵を論理的に渡します（ユーザと厳密に関連しているため）。

他のサービスからこのサービスにどのように問い合わせて、「ねえ、この鍵は正しいのですか？署名を再生成するために必要なすべてのデータをこのリクエストとともに渡します。

GET /user/:user_id/authorization?signature=SOMETHING&data=JSON-DATA-TO-REGENERATE-KEY 

しかし、おそらく、我々はまた、作成されるようにそれを見ることができます：

は、だから私は必要なものを私のような何かを取り払わまし

安らかな方法で権限を確認する方法です新しい認証リソース（何も返されない場合でも、トークンシステムではありません）は、この目的のためにPUTまたはPOSTをより適切に行います。

あなたの見解は何ですか？このような状況に対処する正しいアプローチは何ですか？

Answer 1

このサービスは、認証（公開鍵（USER_ID）のペアと秘密鍵）

を扱いますが、秘密鍵、サーバー側を格納していますか？同じサービスで認証と認証を処理していますか？

私は個人的にWebIDのようなアーキテクチャを好みます。参照：

• http://webid.info
• http://www.w3.org/wiki/WebID

Answer 2

GET /ユーザー/：？のuser_id /承認署名= SOMETHING &データ= JSON-DATA-TO-REGENERATE-KEY

GETメソッドが 'safe'であることを忘れないでください。 「検索以外の行動を取ることの意義がある」べきではない。つまり、クライアントは「副作用を要求すべきではありません」。

Answer 3

個人的には、セッション/ユーザー/それ以外のPOST（それはおそらく）であるはずの初期認証（ログイン）を取得すると何か新しいものが作成されると思います。

その後の承認確認リクエストはGETでなければなりません。それらは新規のものを作成せず、基本的に（応答コードを介して）ブール値を返して、承認ヘッダーが有効かどうかを示します。