Browser support issues aside, if you’re being an Http/hateoas stickler what verbs should the request to log into/out of a site be?
DELETE would seem like the obvious choice but I’m not sure what the resource you’re deleting would be.
2
HTTP is stateless, so you’re never logging in/out of a website, those are just clever names we use for the cookie implementation.
What you actually do is GET an authentication token (cookie), after you POST authentication details. That your browser stores that cookie for you is just a convenience. Finally, after you’re done with your authentication token, you POST that token to the server to let it know that it can be destroyed. Again, this all happens with cookies in the browser as a convenience.
If you want to be an HTTP stickler, your HTTP needs to be stateless (and maybe RESTful).
3
The common choice is POST, and it makes sense. The ‘safe’ verbs (GET, HEAD, OPTIONS, TRACE) are out, because they cannot have semantic side effects that change the observable state of the application (and logging in and out is such a state).
PUT and DELETE are theoretical possibilities; the resource you are creating (PUT) and removing (DELETE) would be the user’s session. However, there are a few oddities about this: first of all, PUT and DELETE, while not safe like HEAD, are still supposed to be idempotent, that is, logging out several times in a row without logging back in would have to be valid, and so would logging in again while still logged in. Furthermore, such a double login cannot alter the state of the application beyond what the first login does, which, considering things like session IDs and such, is problematic. Also, strictly speaking, the URL you are PUTting to is supposed to uniquely identify the resource you are pushing, so in order to be semantically correct, you’d have to PUT to http://example.com/sessions/a8edjn239sd8h2er instead of http://example.com/login, that is, a unique identifier for the session would have to be encoded in the URL – but then, the session ID is generated along with the session, so the ID does not exist yet until after successful login.
The semantics of POST are a much better fit: your login URL (say, http://example.com/login) identifies a resource (the application’s ‘login functionality’) that you are about to “annotate”, that is, it changes an aspect of that resource. Unlike PUT and DELETE, POST requests do not have to be idempotent, which means multiple identical POST requests can continue to change the application state – this is exactly what you want.
Wikipedia’s description of the various verbs is actually quite revealing in this regard:
https://en.wikipedia.org/wiki/HTTP_Verbs#Request_methods
Just want to clarify the accepted answer on how to logout, I use POST to a session resource (http://example.com/sessions/) for Login and the response includes a Location of the newly created session (http://example.com/sessions/a8edjn239sd8h2er).
For Logout, DELETE the session resource pointed by the Location from POST response.
You can Login/Logout multiple of times. Only first DELETE would return no content (204), after that it should return not found response (404). Logging in multiple times will create multiple sessions.
4