

Google is not your daddy: long term reliance on APIs is as bad as outsourcing - xrd
http://www.webiphany.com/2011/05/27/google-is-not-your-daddy-or-long-term-reliance-on-apis-is-as-bad-as-outsourcing/

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

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

The article is not about APIs of libraries.

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

~~~
akronim

         you should NEVER rely on ANY API
    

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.

------
fjabre
But short term has its benefits i.e. Tweetdeck

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

------
chrisjsmith
The sad thing is that this is very true. The worst part is that no-one
believes you until the provider of the API goes under or they break it.

