13

Suppose I have a RESTful authentication endpoint:

http://example.com/api/v1/auth

  • A POST request with email and password allows for logging in. A request gets countered with a response with HTTP 200 for correct login or 403 for incorrect.
  • A DELETE request allows for logging out.

It's obvious that after a successfuly logout I should return HTTP 200. What HTTP response code should I return, if a user tries to logout without being logged in?

Crossfire
  • 1,801
  • 3
  • 21
  • 37

2 Answers2

32

It's obvious that you should return status 200 for successful logout? Not at all. If you don't return a response with that status, then 204 or 205 would be more appropriate (205 = "no content, refresh"), since there is no content to return, and the client should probably refresh its view.

If the user wasn't logged in: Think about what a client would think about it. Either the client wasn't aware that the user wasn't logged in. Or the client wasn't sure whether the user wasn't logged in, and logged out just in case. After the call, the user is logged out. What purpose would it serve to give a different status than for a formerly logged in user? Even if the client detected such a status correctly, what is there that the client could usefully do?

I'd give the exact same response. Don't see it as "I was logged out", see it as "I am not logged in". If you really want to report it, return status 200 with a different content for users that were logged in and users that were not logged in.

gnasher729
  • 51,477
  • 5
  • 75
  • 98
  • 1
    I think you should only logout as an authenticated user because otherwise one could place something like `` on a random page and logout the user. Now in the case of the question here OP only uses DELETE request, but still. Wanted to add that. – handy Nov 05 '20 at 20:44
2

The short answer to your question is 404. Here's why: DELETE means "delete the resource identified by the URL," so a successful request to DELETE /api/v1/auth should delete whatever /api/v1/auth identifies, causing subsequent requests to DELETE /api/v1/auth to return 404 Not Found.

The problem with DELETE is that, ideally, /api/v1/auth, like any other URL, should represent the same resource regardless of whether the current user is logged in or not and regardless of the identity of the logged-in user; so if one user asks the server to DELETE this resource and receives a 2xx response, any subsequent request, by any user, to POST /api/v1/auth (logging in) or DELETE /api/v1/auth (logging out) should fail and return 404.

Therefore I think it's better to implement both login and logout by POSTing to two different resources, e.g. /api/v1/auth/login and /api/v1/auth/logout.

Ron Inbar
  • 2,044
  • 1
  • 16
  • 26