REST design of authenticate calls

In my "REST API" I would like to use some token based / cookie based authentication. That means, before the API can be used by consumer the consumer needs to obtain this token by calling some Authentication URL with username/password.

Is it OK to just return a Set-Cookie Header?

I think it actually breaks the REST principle but how would you do it (or design the uris and verbs) without HTTP Basic Auth (which means sending username/pwd in every request)?

Maybe like this?

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

or?

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

What about registration then?

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

or?

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)

---

I would treat a session as a resource:

POST /sessions

Creates a session and returns a cookie.

DELETE /sessions/:sessionid

To delete the cookie and log off.

GET /session/:sessionid

To check if the session is valid (eg Cookie didn't expire or otherwise invalidated).

But I think you should also implement Basic Auth or some other scheme that's standard and require a your custom session stuff to be authenticated via it while the rest of the API could also use the session data via the cookie.

---

For username/password authentication I would use HTTP Basic Authentication

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

The advantage is that most HTTP client libraries support it out-of-the-box. More advanced methods exist if you need them (digest, oauth, etc.). I would try not to invent my own and I would avoid cookies.

链接地址: http://www.djcxy.com/p/7922.html

上一篇: REST API服务返回验证失败的适当HTTP状态代码是什么？

下一篇: 认证呼叫的REST设计