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