3 ms·

The redundant pageloads provide a better experience to some of your users. Doesn't that make it worth it?

by jfoster 15y ago

dangrossman 15y ago
Not when it screws things up. 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... This is a dangerous feature.
- bambax 15y ago
  This problem used to exist for a Google optimizer of some kind, a long time ago (6-8 years ago I think). Do you remember its name?
- lol_hn 15y ago
  maybe it'll cause you to stop being a fucking moron and causing side-effects on a GET request
  - deleted 15y ago
    [deleted]
- 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.

The redundant pageloads provide a better experience to some of your users. Doesn't that make it worth it?

by jfoster 15y ago

The redundant pageloads provide a better experience to some of your users. Doesn't that make it worth it?

Not when it screws things up. 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... This is a dangerous feature.

bambax 15y ago
This problem used to exist for a Google optimizer of some kind, a long time ago (6-8 years ago I think). Do you remember its name?
lol_hn 15y ago
maybe it'll cause you to stop being a fucking moron and causing side-effects on a GET request
- deleted 15y ago
  [deleted]
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.