5 ms·

> As a rule, HTTP GET requests should not modify server state. This rule is useful because it lets intermediaries infer something about the request just by look

> As a rule, HTTP GET requests should not modify server state. This rule is useful because it lets intermediaries infer something about the request just by looking at the HTTP method. 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).

epanastasi 12y ago
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 http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
- muaddirac 12y ago
  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.
- SilasX 12y ago
  Safe implies idempotent. "Same effect from 0 or more actions" implies "Same effect from 1 or more actions".
  - charonn0 12y ago
    All safe methods are idempotent, but not all idempotent methods are safe (e.g. PUT or DELETE.)
  - marcosdumay 12y ago
    Safe means you can call it in any way you want. Like from a bot, or an accelerator plugin.
ccleve 12y ago
One reason to not use GET to modify server state is that bots and crawlers may hit your api. They almost universally use GET and not POST.
- sitkack 12y ago
  if your api is modifying server state w/o HMAC, api is probably broken.
  - dspillett 12y ago
    HMAC won't save you if the application is public (and therefore available to scrapers. If a search engine or other bot can get a link to the page from another page in the app just as any interactive user would, it can also get a link with a correct HMAC token just as any interactive user would.
    - sitkack 12y ago
      That isn't how HMAC works. http://en.wikipedia.org/wiki/Hash-based_message_authentication_code http://en.wikipedia.org/wiki/Hash-based_message_authenticati... 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.
      - dspillett 12y ago
        For an authenticated user, yes, as you have somewhere to hang a known-by-the-server-but-unknown-elsewhere key from. 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...

epanastasi 12y ago

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 http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

muaddirac 12y ago
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.
SilasX 12y ago
Safe implies idempotent. "Same effect from 0 or more actions" implies "Same effect from 1 or more actions".
- charonn0 12y ago
  All safe methods are idempotent, but not all idempotent methods are safe (e.g. PUT or DELETE.)
- marcosdumay 12y ago
  Safe means you can call it in any way you want. Like from a bot, or an accelerator plugin.

ccleve 12y ago

One reason to not use GET to modify server state is that bots and crawlers may hit your api. They almost universally use GET and not POST.

sitkack 12y ago
if your api is modifying server state w/o HMAC, api is probably broken.
- dspillett 12y ago
  HMAC won't save you if the application is public (and therefore available to scrapers. If a search engine or other bot can get a link to the page from another page in the app just as any interactive user would, it can also get a link with a correct HMAC token just as any interactive user would.
  - sitkack 12y ago
    That isn't how HMAC works. http://en.wikipedia.org/wiki/Hash-based_message_authentication_code http://en.wikipedia.org/wiki/Hash-based_message_authenticati... 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.
    - dspillett 12y ago
      For an authenticated user, yes, as you have somewhere to hang a known-by-the-server-but-unknown-elsewhere key from. 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...