Therefore the results are different for different states and it is not idempotent.
Therefore the results are different for different states and it is not idempotent.
In this case, logging out multiple times does not change anything from the first application.
sending notifications, updating counters, etc. all could be result of logging out.
Now, you got a point about idempotence from the server's point of view. However, it would take a _badly_ programmed website for the logout operation to _not_ be idempotent. Sending notifications, updating counter, etc. _without first checking if the user is really logged in or not_ is simply moronic. This simple check is what would turn the logout operation into an idempotent one in the server too.
No, from all states, the result is that you're logged out.
Similarly, changing a customer's address is typically
idempotent, because the final address will be the same
no matter how many times it is submitted.
So, even if in one case there's an internal state change (going from an old address to a new one) whereas in the other there is not (going from the new address to the new one again), it is commonly considered idempotent because the end result is the same.[1] http://en.wikipedia.org/wiki/Idempotence#Computer_science_me...
Edit: Next paragraph says:
This is a very useful property in many situations, as it means that an operation can
be repeated or retried as often as necessary without causing unintended effects.
With non-idempotent operations, the algorithm may have to keep track of whether the
operation was already performed or not.
"A change in state" would be an unintended effect I think.The HTTP spec clearly talks in terms of the effect of sequences of repeated operations, not in terms of the results of individual operations. The side effects of a single logout are the same as for 6 - you are logged out and whatever logout triggers exist are executed once.
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1...