RESTfully design /login or /register resources?

Qcom picture Qcom · Aug 21, 2011 · Viewed 82.1k times · Source

I was designing a web app and then stopped to think about how my api should be designed as a RESTful web service. For now, most of my URI's are generic and might apply to various web apps:

GET  /logout   // destroys session and redirects to /
GET  /login    // gets the webpage that has the login form
POST /login    // authenticates credentials against database and either redirects home with a new session or redirects back to /login
GET  /register // gets the webpage that has the registration form
POST /register // records the entered information into database as a new /user/xxx
GET  /user/xxx // gets and renders current user data in a profile view
POST /user/xxx // updates new information about user

I have a feeling I'm doing a lot wrong here after poking around on SO and google.

Starting with /logout, perhaps since I don't really GET anything - it may be more appropriate to POST a request to /logout, destroy the session, and then GET the redirect. And should the /logout term stay?

What about /login and /register. I could change /register to /registration but that doesn't alter how my service fundamentally works - if it has deeper issues.

I notice now that I never expose a /user resource. Perhaps that could be utilized somehow. For instance, take the user myUser:

foo.com/user/myUser

or

foo.com/user

The end user doesn't require that extra verbosity in the URI. However, which one is more appealing visually?

I noticed some other questions here on SO about this REST business, but I would really appreciate some guidance on what I've laid out here if possible.

Thanks!

UPDATE:

I would also like some opinions on:

/user/1

vs

/user/myUserName

Answer

ndp picture ndp · Aug 31, 2011

RESTful can be used as a guideline for constructing URLs, and you can make sessions and users resources:

  • GET /session/new gets the webpage that has the login form
  • POST /session authenticates credentials against database
  • DELETE /session destroys session and redirect to /
  • GET /users/new gets the webpage that has the registration form
  • POST /users records the entered information into database as a new /user/xxx
  • GET /users/xxx // gets and renders current user data in a profile view
  • POST /users/xxx // updates new information about user

These can be plural or singular (I'm not sure which one is correct). I've usually used /users for a user index page (as expected), and /sessions to see who is logged in (as expected).

Using the name in the URL instead of a number (/users/43 vs. /users/joe) is usually driven by the desire to be more friendly to the users or search engines, not any technical requirements. Either is fine, but I'd recommend you are consistent.

I think if you go with the register/login/logout or sign(in|up|out), it doesn't work as well with the restful terminology.