[kilburn]

From the Wikipedia article on Idempotence [1]:

  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...

[firat]

Okay, I understand that the formal definition of "idempotent" is different than what the author means. What is the correct term to use in this case?

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.

[saurik]

I think the best "term" you can use here is "side effect free". I almost wanted to say "pure" would work, but there is no real requirement that GET always return the same thing: it just needs to not change the state of the server in a way that a later GET could detect (although, honestly, you really only practically care about "find bothersome", and if there is a term for "bothersome side effect free" it would probably be from medicine and not computer science).