認証呼び出しのREST設計

Question

私の「REST API」では、トークンベース/クッキーベースの認証を使用したいと考えています。つまり、APIをコンシューマが使用できるようになる前に、消費者はusername/passwordの認証URLを呼び出してこのトークンを取得する必要があります。

Set-Cookieヘッダーを返すだけでよいですか？

実際にはRESTの原則が破られていると思いますが、HTTP Basic Auth（リクエストごとにユーザー名/パスワードを送信することを意味します）を使わずに、どのように（またはurisとverbを設計するのですか）

このようなのでしょうか？

GET api/authentication/signin/?username=abc&pwd=123 
GET api/authentication/signout 

または？

GET api/user/authtoken/?username=abc&pwd=123 (signin) 
DELETE api/user/authtoken/  (signout) 
GET api/user/    (returning details of the current user) 

登録はどうですか？

POST api/user/ (which would also return an authtoken) 

または？

GET api/user/abc/authtoken/?pwd=123 (signin of user abc) 
DELETE api/user/abc/authtoken/  (signout) 
GET api/user/abc/    (returning details of user abc) 

Answer 1

私は、資源としてのセッションを扱います：

POST /sessions 

は、セッションを作成し、クッキーを返します。

DELETE /sessions/:sessionid 

クッキーを削除してログオフする。

GET /session/:sessionid 

セッションが有効かどうかを確認する（Cookieが有効期限切れになっていないか無効化されているなど）。

でも基本認証やその他の標準の実装が必要だと思っています。カスタムセッションを使って認証する必要がありますが、他のAPIもセッションデータを使用できます。

Answer 2

ユーザー名/パスワード認証のために、私は基本認証HTTP

http://en.wikipedia.org/wiki/Basic_access_authentication

を使用する利点は、ほとんどのHTTPクライアントライブラリは、アウト・オブ・ボックス、それをサポートしていることです。必要に応じて、より高度な方法が存在します（ダイジェスト、オウトなど）。私は自分自身を発明しないことを試み、私はクッキーを避けるだろう。