[epanastasi]

Actually there are two guarantees for GET:

1) It is a "safe" method.

2) It is an idempotent method.

A safe method (GET/HEAD) should not modify server state.

"In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. "

Whereas PUT & DELETE are also idempotent but not "safe".

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

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

[SilasX]

Safe implies idempotent.

"Same effect from 0 or more actions" implies "Same effect from 1 or more actions".

[charonn0]

All safe methods are idempotent, but not all idempotent methods are safe (e.g. PUT or DELETE.)

[marcosdumay]

Safe means you can call it in any way you want. Like from a bot, or an accelerator plugin.