As long as we're picking nits, it doesn't really matter if a GET request modifies server state so long as the state after N requests is the same as the state after 1 request (idempotence).
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".
> 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.
Of course, it's not actually-invisible: their next request might be a little bit faster.
"Same effect from 0 or more actions" implies "Same effect from 1 or more actions".
The private key of the API user is hashed with the full URL of the service. The user id is sent in the header of the request. The server looks up the user id and gets their private key, it then uses that key to hash the URL, comparing it to the one passed.
There is no way for a scraper or bot to get the HMAC token.
For a public interface you don't necessarily have that. Though once you are dealing with a service that can be modified by unauthenticated users you have larger problems from malicious interactive users than from accidents by scrapers, so I'm probably arguing an irrelevant point...