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.
Then the API owners will realize they shouldn't break the HTTP standard just because it happened to work before.
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.