4 ms·
After lots of notifications, warnings and headers: > first they disabled it for one hour, then reenabled it, then they disabled it permanently two weeks later.
by laurent92 6y ago
After lots of notifications, warnings and headers:
> first they disabled it for one hour, then reenabled it, then they disabled it permanently two weeks later.
> There's other tricks too: Android added increasing delays to deprecated native APIs in 2015, eventually going up to a full 16 second wait, before finally turning off the API entirely.
I feel that this is the crux. You never know who actually uses the API until it is really unavailable.
- toast0 6y ago> You never know who actually uses the API until it is really unavailable. You should have a pretty good idea who's using an HTTP API from access logs. In an ideal world, User-Agent headers help you trace usage down; although that's hard to enforce on a public API. Depending on how much introspection is going on, Google should have a pretty good idea who's using deprecated APIs among those who submitted their apks to Google Play. Yeah, there's probably going to be things that slip through the cracks, but you should be able to track down a lot of things first. And if you can't shim your old API onto your new API, maybe people aren't transitioning because your new API sucks :P
- rollcat 6y agoAnother trick is failure injection, e.g. go for a 404/410 for a small % of all requests or clients to figure out potential impact and give an early warning, then slowly ramp up the %.