Tuesday, November 20th, 2012

According to HTTP methods Logging out is a POST

Here's some non-specific Python food for thought... According to the HTTP specification, GET requests should have no effects. However, isn't logging out of a website an effect? Thus, logging out of a website should imply a POST for the logout to be successful. Technically, if one does a GET request to a Logout URL, it should confirm with the user if they really want to logout and then perform a POST back to the same URL to complete their request.

What are your thoughts on the whole logout situation? Should GET be used to actually log the user out, or should a POST be used for this? I personally just think most web developers are too lazy to make the logout a POST form, since it is easier to just create an A tag in HTML and be done with it.

Comment #1: Posted 8 years, 11 months ago by Martin Rio

That's a great question and possibly and edge case. I believe the no effect primer of REST is mostly thought of as no effect on resource models managed by the service and not as general as "no effect whatsoever".

Comment #2: Posted 8 years, 11 months ago by Chris Pratt

Along the lines of Martin's reasoning, GET should have no effect on the managed data store of the API, not necessarily no effect at all. One of the core constraints of REST is Stateless. Session is a explicit violation of REST. In a true REST interaction, there's no such thing as "logging out", because each request is responsible for its own state, passing along something like an auth token if an endpoint requires authorization. "Logging out" would simply be not sending any authorization with the request. So, since session storage is a violation of REST in the first place, I see nothing wrong with using whatever HTTP verb you like to interact with it.

Comment #3: Posted 8 years, 11 months ago by karl

Side effects mean on the information structure. Doing a GET doesn't change the information space at the HTTP level. Note also that what is happening outside of the HTTP surface (cms, storage, etc) is out of scope of HTTP. You have to consider what is only accessible from the HTTP point of view.

@Martin Rio. Idempotent is a property of HTTP not REST. ;)

@ChrisPratt. Stateless is a property of HTTP, not REST. ;)

Comment #4: Posted 8 years, 11 months ago by Mark Lakewood

Surely its a DELETE. REST/Http has more verbs than just GET and POST. It certainly isnt a post, as in my head a post is a create statement that you can do over and over.

So therefore, its easiest to just do a DELETE on the session?

Comment #5: Posted 8 years, 11 months ago by Anonymous

I want to contribute with a few thoughts. I have seen this stuff in every HTTP vs REST discussion on the net.

HTTP is not REST. I am not talking about the intents of the HTTP specification. Is not REST by a matter of fact. Then I take the HTTP specification restrictions as general usage guidelines instead of fix rules. Also, HTTP violates the stateless principle constantly. As a broad example, any GET call done between two other identical GET calls should not affect the results from the latter, but it of course does in the presented case.

There is not sense at all in the imposition of REST principles to HTTP. Current state of art is going to ignore you. There also not sense in the imposition of HTTP principles currently abandoned by the general practice.

Said that, I do not think the change proposed by KV is convenient. Despite the fact that every GET HTTP request is actually a POST request (they always have state information, cookies, ...), I think the usage difference between them should stick to common use and application intention. Providing support to the tools grown surrounding the current usage patterns looks more adequate (antivirus software, navigation control, proxies, ...).

Stick to GET. Is my opinion, of course. I always love the "practicality beats purity". And in this particular case you exposed, every developer out there understand the reasons for HTTP to be like it is.

Also, you can not control the client browser/request behaviour. Forcing a POST using a form element is not going to make it a better request, or a better practice in terms of HTTP actual usage.

Comment #6: Posted 8 years, 11 months ago by Kevin Veroneau

@Mark, a DELETE does make more sense than a post, but unfortunately current-gen browsers do not support this verb when using forms. It is planned in the future for the W3C standard though, as I have read.

@karl, if you think of WebDav, it actually modifies storage, and I believe it's an extension of HTTP... Not really sure how WebDav works besides it working with HTTP.

@Martin, Chris, I don't believe I mentioned REST in my article at all, this is more of a general HTTP spec thing.

Comment #7: Posted 8 years, 11 months ago by Sybren

I agree that it should be a POST. So should be things like unsubscribing from a mailing list, to name another case in which often a GET is used.

About Me

My Photo
Names Kevin, hugely into UNIX technologies, not just Linux. I've dabbled with the demons, played with the Sun, and now with the Penguins.

Kevin Veroneau Consulting Services
Do you require the services of a Django contractor? Do you need both a website and hosting services? Perhaps I can help.

This Month

If you like what you read, please consider donating to help with hosting costs, and to fund future books to review.

Python Powered | © 2012-2019 Kevin Veroneau