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 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.