I have a REST API for placing automated phone calls, for example, which I regularly test using my browser. Chrome is going to start calling people when I've half way finished typing a URL because it thinks it knows what I'm going to type. That's not only not what I want, but costs real money.
Or what if I'm an administrator for some user-generated content site. I have a webpage that shows me a list of user accounts and lets me click a "delete all this user's content" link to fix someone's mistake by request. Now in the process of typing the URL to get to this admin area, Chrome thinks I'm trying to go to the "delete all" page and accesses it in the background...
It was an example; these APIs clearly exist in the wild, and side effects are not the only danger of prefetching API URLs. What if a URL that is meant to be accessed with a GET request that kicks off an expensive, long-running process is prefetched?
There's a front page story right now about Google AppEngine, where the linked discussion mentions mashing a link to start a MapReduce job every day that's costing $200-300 a day to run. What if Chrome autocompletes the URL to that job, costing you $300 before you finish typing something else?
What if a URL that is meant to be accessed with a GET request that kicks off an expensive, long-running process is prefetched?
Then the API owners will realize they shouldn't break the HTTP standard just because it happened to work before.
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. These methods
ought to be considered "safe". This allows user agents to represent other methods,
such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact
that a possibly unsafe action is being requested.
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.
This argument comes up every time there's a breaking change, but developers should be responsible for their actions. They broke the spec, they should be deal with the consequences.