1

I'm new to REST design so I'd like some pointers here.

Here is what I have so far:

GET    /api/users                 //all users
GET    /api/users/123             //specific
GET    /api/users/me              //get your own profle 
POST   /api/users/me/session      //start new session (login)
DELETE /api/users/me/session      //ends the current session (logout)

I'm wondering about the session / login/out stuff here. Am I thinking correct here or should it be designed in some other way to be more REST'ish?

Also, what about register user, should that be:

POST /api/users

Even if it also starts a new session?

Roger Johansson
  • 22,764
  • 18
  • 97
  • 193

2 Answers2

1

I would recommend to avoid the term session and use auth (as in authentication). The term session gives an impression of a server-side session which normally goes against REST.

The following are good:

GET    /api/users                 //all users
GET    /api/users/123             //specific
GET    /api/users/me              //get your own profile

For authentication, you may have this:

POST   /api/auth                  //username/password required. auth_token is sent back
DELETE /api/auth                  //auth_token is sent in HTTP header
Aziz Shaikh
  • 16,245
  • 11
  • 62
  • 79
1

REST is stateless, meaning that the server does not need to to keep an active state on the connected application. To quote Roy Fielding:

All REST interactions are stateless. That is, each request
contains all of the information necessary for a connector to
understand the request, independent of any requests that may
have preceded it

A common way to authenticate users is to add a 'secret' or access token to the authentication headers of the requests, which you can implement with e.g. OAuth

Also, when you add authentication headers there is not need to distinguish between:

GET    /api/users/123             //specific
GET    /api/users/me              //get your own profile

as you can simply check server side if the requested user's token matches the one in the authentication header, you return the 'me' profile. And POST /api/users is indeed an approach to adding users to the system. Hence:

GET    /api/users     //all
GET    /api/user/{id} //a user
PUT    /api/user/{id} //update
POST   /api/user      //Add new user
DELETE /api/user/{id} //Remove user
dsfgsho
  • 2,731
  • 2
  • 22
  • 39
  • even if I would use a secret token and headers. I would still need some "InvalidateToken" request to logout, right? – Roger Johansson Aug 20 '13 at 08:46
  • @RogerAlsing No. If the client does not send the token, then the request is not authenticated. There is no "logged in" and "logged out" from the server's perspective. However, you can make the illusion of it on the client if you like. – Darrel Miller Aug 20 '13 at 12:40
  • That said, you can in fact combine multiple approaches. It is e.g. quiet common to use the .net WebApi stack together with SignalR (http://signalr.net/) a persistent messaging framework that allows you to push updates to clients. You can e.g. use REST calls within one of these authenticated persistent connections. – dsfgsho Aug 21 '13 at 19:42