4 ms·

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,

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 12y ago
...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 12y ago
  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.