Will the browser cache XMLHTTPRequest GET requests? I hadn't realized it would do that.
I agree that if anything between you and the server is going to cache requests then you need well-specified behavior around that. But that particular problem can be solved by a specification much, much simpler than all of HTTP.
I also see that it's useful to know that certain requests will not be state-changing for purposes of pre-fetch. But while I agree this is important for the browser, I question how important it is for APIs. API calls are usually constructed programmatically -- V8 isn't going to start just randomly guessing what XMLHTTPRequests you might come up with next and start fetching them. This is where I think that browser-based paradigms with a human user diverge from programmatic ones.
It costs nothing to switch those GETs to POSTs (or fucking whatever method best describes the kind of side effect you're doing). why are we making excuses for doing the obviously wrong thing?
I get what you're saying about the API… but if you're going over HTTP why not play by HTTPs rules. Presumably it's an app that is the primary consumer of the API so they could use any sort of protocol. Why decide to use HTTP but not conform to the standard in a way that ruins any benefit you might have got out of using HTTP instead of say:: OSC or.. basically anything OTHER than http would be better.
If we're talking about using HTTP to bust through a firewall, then that stuff is DEFINITELY going to break unless you use HTTP in as dull and ordinary a way as possible, and GET requests will always be cached by god knows how many different machines between you and the car.
If it's not an app, then we've decided to put a webserver on the car so that we can serve a website with some javascript that does XHR calls to make things happen. I would not put it past google to make a future version of chrome that prefetches JSON api requests. But regardless, yes, XHR calls do go via the browser cache. and the proxy cache. and the firewall. and any other machine that makes basic assumptions about what those methods mean.
> why are we making excuses for doing the obviously wrong thing?
Sorry if I was unclear -- I wasn't advocating a mis-designed API, I am suggesting that HTTP is way more complicated and subtle than it needs to be for the purposes of remote APIs.
I concede that providing enough information to know what is cacheable (and what the caching key is, etc) is justified complexity. But I think that the other 95% of semantics that "pure" REST demands you follow are pretty useless and pedantic.
I agree that if anything between you and the server is going to cache requests then you need well-specified behavior around that. But that particular problem can be solved by a specification much, much simpler than all of HTTP.
I also see that it's useful to know that certain requests will not be state-changing for purposes of pre-fetch. But while I agree this is important for the browser, I question how important it is for APIs. API calls are usually constructed programmatically -- V8 isn't going to start just randomly guessing what XMLHTTPRequests you might come up with next and start fetching them. This is where I think that browser-based paradigms with a human user diverge from programmatic ones.