Suppose I have a RESTful authentication endpoint:
http://example.com/api/v1/auth
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.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?
If it's a stateless endpoint (api) you could return 200 (if your response contains some content, like in your code) or 204 (if no content is returned). If it's session based (web), you can redirect the user to the "home" page and return 302, like Laravel does.
The HyperText Transfer Protocol (HTTP) 301 Moved Permanently redirect status response code indicates that the requested resource has been definitively moved to the URL given by the Location headers.
Even stateless sessions should report log-out events to the server, which should be done via a POST request.
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.
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 POST
ing to two different resources, e.g. /api/v1/auth/login
and /api/v1/auth/logout
.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With