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.

closed as primarily opinion-based by durron597, user40980, user22815, GlenH7, Kilian Foth Aug 7 '15 at 13:28

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • You should make sure that any verb you choose is available on target platform. If you are targeting web browsers, not all browsers support all HTTP verbs. – grizwako May 3 '13 at 9:58
  • 1
    @GrizzLy, that's true, this is more a question of theory as I couldn't readily think of what the correct answer was. – George Mauer May 3 '13 at 20:23

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).

  • 1
    So to clarify, would you agree that Logout should be a client-side only operation (ie delete the cookie) after which the client should probably move to the entry point of the API? – George Mauer May 3 '13 at 20:28
  • 1
    Yes and no. The client should inform the server that the session can be destroyed for security purposes. – Jonathan Rich May 3 '13 at 20:39

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:



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.

  • See, this is what I was thinking initially, but what would GET http://example.com/sessions/a8edjn239sd8h2er return? Worse, shouldn't GET ://example.com/products return the same thing whether or not you've previously POSTed to http://example.com/sessions/ or not? After some thought, I think @JonathanRich might have nailed it. – George Mauer May 3 '13 at 20:27
  • 1
    @GeorgeMauer I do agree that HTTP is stateless. GET example.com/products still return the same thing, if you want it to return something. GET /products can also return unauthorized (401) if the client is not authenticated. I didn't want to go into the authentication details because there are too many different implementations. But, with I've used this method to return auth token with GET example.com/sessions/a8edjn239sd8h2er and set the token in Authorization header. This way clients don't need to have cookie (can be easier for non-browser apps). – imel96 May 6 '13 at 1:45
  • Ah, so you're saying you GET the auth token and then include that along as a parameter for all other requests? (Which I guess is what the cookie approach is already doing just using cookies) – George Mauer May 6 '13 at 14:21
  • @GeorgeMauer yes, but include it as Authorization header, not parameter. This is also how it's done in basic authentication and OAuth. It is similar with cookie but people tend to make the application stateful when using cookie. – imel96 May 6 '13 at 23:13

Not the answer you're looking for? Browse other questions tagged or ask your own question.