3 ms·

It would appear that you actually do not have a REST API. GET requests may not cause side effects in a REST API. This is an important feature of REST. On the o

by maggit 15y ago

It would appear that you actually do not have a REST API. GET requests may not cause side effects in a REST API. This is an important feature of REST. On the other hand, there are probably many HTTP based APIs that cause harmful side effects on GET, so the danger is still lurking.

dangrossman 15y ago
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?
- icebraining 15y ago
  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.

by maggit 15y ago

dangrossman 15y ago

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?

icebraining 15y ago
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.