RESTfully design /login or /register resources?

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

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.

One thing sticks out in particular as not REST-ful: the use of a GET request for logging out.

(from http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Safe_methods)

Some methods (for example, HEAD, GET, OPTIONS and TRACE) are defined as safe, which means they are intended only for information retrieval and should not change the state of the server. In other words, they should not have side effects, beyond relatively harmless effects such as logging, caching, the serving of banner advertisements or incrementing a web counter. [...]

[... H]andling [of GET requests] by the server is not technically limited in any way. Therefore, careless or deliberate programming can cause non-trivial changes on the server. This is discouraged, because it can cause problems for Web caching, search engines and other automated agents [...]

As for logging out and redirecting, you could have a post to your logout URI give a 303 response redirecting to the post-logout page.

http://en.wikipedia.org/wiki/Post/Redirect/Get

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

Edit to address URL design concerns:

"How do I design my resources?" is an important question to me; "how do I design my URLs?" is a consideration in two areas:

URLs that users will see should not be too ugly and meaningful if possible; if you want cookies to be sent in requests to some resource but not others, you'll want to structure your paths and cookie paths.

If JRandomUser wants to look at his own profile and you want the URL to be prettier than foo.com/user/JRandomUser or foo.com/user/(JRandom's numeric user id here), you could make a separate URL just for a user to look at their own information:

GET foo.com/profile /*examines cookies to figure out who 
                     * is logged in (SomeUser) and then 
                     * displays the same response as a
                     * GET to foo.com/users/SomeUser.
                     */

I would claim ignorance much more readily than wisdom on this subject, but here are a few resource design considerations:

1. Consumer: which resources are meant to be viewed directly in a browser, loaded via XHR, or accessed by some other kind of client?
2. Access / identity: does the response depend on cookies or referrers?