Anyone who's developed things using Google's APIs in the past decade has learned to expect them to shut down at some point. That's not a reason to avoid them entirely, but it is a reason to architect your app to make it easier to change.
There is not just a computing resource cost involved - keeping an API around means continuing to support the quirks of that interface, which means code complexity and maintenance costs, especially when the system the API talked to gets refactored and/or overhauled. Google's internal refactoring strategy frequently relies heavily on a monolithic code repository and the ability to rebuild the world; the more that interfaces are unable to change the harder refactoring becomes.
3) How many times a month will the API you're using get deprecated and how much developer time will you have to dedicate to keeping up with Google's API changes?
Migrating to better APIs is done all the time. It is not an issue worth discussing about anymore. But even if you have to maintain an API this doesn't mean you cannot change the underlying implementation.
I'm not sure I understand what you are asking. From Google's perspective, to shut down the API is simple: they just need to stop serving the requests they get to the API and that will shut it down.
If you are asking how to responsibly shut down an API, that is a hard thing to do. Having the API start failing intermittently a bit more than a month after you announce it won't be supported any longer is definitely not the right way to do it though. Giving people plenty of advanced warning is the least you can do, even if you technically _can_ shutdown the API whenever you feel like it.
> 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
> you can't control when your user will update, if they do at all
If you design your APIs to be versioned from the start, you don't need to be overly concerned with that. Also, if maintaining a deprecated API is too resource-consuming (either developers or API translation logic) you can always make it return a message informing the user the said API will cease to function on a given date (you need to make the app display that, even if not updated) and shut it down after that. Any mobile app should have a way to be placed in degraded functionality mode for a number of reasons, API deprecation being just one of them.
Right, but in this case, changing the target API is what broke the app. Since Google won't allow you to release an update with an old target API, you can't just revert the change and increase the build number.
Google's product explosions / surprise deprecations possibly hint that this is what happens? Changing the API becomes cumbersome, so you just make a new product with a new API to do an end-run around the requirement...
If that's really the official attitude within Google, then I will stay away from using Google's APIs and will advise other companies to do the same.
We should be talking about 10-year deprecation for APIs. Not 1 year.
Software development is a huge capital expense. Talented developers are a limited resource. Forcing your paying customers to go spend a bunch of valuable $$$ and time in order to just move to the latest version of your API -- not even to gain any new functionality, but to keep what was working already! -- is simply unacceptable.
The thing about API and platforms is, stability matters, and it matters a lot. Google can't stop fiddling with things, their products and their APIs and legal terms; they just keep changing things constantly. It makes it incredibly annoying to build anything on Google tech.
Things built on Microsoft tech still work decades later without any change. I have things built on AWS that's still running on 6 year old APIs and they still work. With Google, I'm lucky if it lasts 6 months.
According to your own citation, Google deprecated multiple APIs every year. So the odds of Google cutting off access to an API you use may be decreasing... But it's still nowhere near zero, and it's still a valid concern.
> If you change your service’s API, just updating all of the other clients of your service in the repo is not sufficient to skirt the problem of different clients expecting different APIs.
Most Google APIs are written in protobuf, which is backwards compatible over the wire. This makes most changes painless, although caveat emptor as things can still get messy as they do in the real world. With something like a Java interface, it doesn't really matter if those APIs change because all the code is built and released together at HEAD.
reply