I think a development team needs to ask itself if the api is stable and has a stable team behind it. Example Java libraries. If so, use it. If it has a company like Google or a small open source team, then protect your self by isolating the use of the api. Create a library that maps from your own internal api to the outside api. Even if it is a direct one-to-one mapping, you have only one place to make changes if the outside api becomes an orphan.
I don't think "API" is used in the same sense as what you are using it in. The author is talking about not building your business around an API offered by external service provider (eg: Google Translate, or Twitter for example) where your business is dependent upon the the external party continuing to offer that API.
Both Google and developers are at fault here. If even Google can't keep an API alive for more than a couple of years, I think it goes without saying you should NEVER rely on ANY API, simply because you should never rely on any other company to dictate your business success or failure. You can test with APIs, play with data, use them as a form of redundancy or simplification of a longer process, but if you're build a sandcastle with other people's sand, you have no one to blame but yourself. You're building a bullshit company.
On the other hand, Google has clearly gone the way of flighty Yahoo, coming out with promising tools then letting them die on the vine. This is not OK - they are wasting developers' time, consumers' time and their own staffs' time. So you can't argue that Google isn't at fault here.
Well that's a bit extreme, a better approach would be to acknowledge that your reliance on an external API is a risk that you're taking in order to save the development costs of DIY. If it's critical to your system, you need to have as part of your risk management a plan B that you can either switch to, or develop in the background. But overall trading development time for some risk makes sense a lot of the time.
Unless the API is something with no alternative, and not easy to replicate, then you have an issue.
It is obviously a risk/reward scenario. Of course, you can use the APIs and you can succeed, but I don't want to hear people bitching about how the rug is pulled out from under them when that was the arrangement all along.
