Menu
This question is not about when to use GET or POST in general; it is about which is the recommended one for handling logging out of a web application. I have found plenty of information on the differences between GET and POST in the general sense, but I did not find a definite answer for this particular scenario.
As a pragmatist, I'm inclined to use GET, because implementing it is way simpler than POST; just drop a simple link and you're done. This seems to be case with the vast majority of websites I can think of, at least from the top of my head. Even Stack Overflow handles logging out with GET.
The thing making me hesitate is the (albeit old) argument that some web accelerators/proxies pre-cache pages by going and retrieving every link they find in the page, so the user gets a faster response when she clicks on them. I'm not sure if this still applies, but if this was the case, then in theory a user with one of these accelerators would get kicked out of the application as soon as she logs in, because her accelerator would find and retrieve the logout link even if she never clicked on it.
Everything I have read so far suggest that POST should be used for "destructive actions", whereas actions that do not alter the internal state of the application -like querying and such- should be handled with GET. Based on this, the real question here is:
Is logging out of an application considered a destructive action/does it alter the internal state of the application?
580
If logging out happens over GET, a prefetching process could inadvertently log the user out after logging in. Even stateless sessions should report log-out events to the server, which should be done via a POST request.
For login request we should use POST method. Because our login data is secure which needs security. When use POST method the data is sent to server in a bundle. But in GET method data is sent to the server followed by the url like append with url request which will be seen to everyone.
No, a logout is not useless in a REST API. In fact, for APIs that require authentication, it is more or less a necessity. It appears that your implementation isn't using JWT if you have to “delete token information and any other type of authentication for the logged in user...”
In summary, the HTTP method most often used for authentication is POST because it allows authentication information to be sent through the more secure request body and because authentication requests are often non-idempotent which best fits the intended use of POST.
In REST there should be no session, therefore there is nothing to destroy. A REST client authenticates on every request. Logged in, or out, it's just an illusion.
What you are really asking is should the browser continue sending the authentication information on every request.
Arguably, if your application does create the illusion of being logged in, then you should be able to to "log out" using javascript. No round trip required.
Fielding Dissertation - Section 5.1.3
each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client
39
Use POST.
In 2010, using GET was probably an acceptable answer. But today (in 2013), browsers will pre-fetch pages they "think" you will visit next.
Here is one of the StackOverflow developers talking about this issue on twitter:
I'd like to thank my bank for making log off a GET request, and the Chrome team for handy URL prefetching.- Nick Craver (@Nick_Craver) January 29, 2013
fun fact: StackOverflow used to handle log-out via GET, but not anymore.
88
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
