[muaddirac]

Also from that RFC:

> Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.

I guess my point is that idempotence is the aspect that matters to clients - you can have side-effects if you really want, so long as the request can be safely repeated.

[meejah]

...and in fact, there's a popular use-case called "using memcached" that does have side-effects. That is, doing a GET on something absolutely changes the server "state" (in the sense that memcached might have a key added to it) but that should be invisible to the user.

Of course, it's not actually-invisible: their next request might be a little bit faster.

[dragonwriter]

Its probably better to think of GET as not affecting the state of the resources within the API rather than not affecting the state of the server.