
APIs Are Forever, Wait No...They Can Go Away at Any Time - apievangelist
http://www.apievangelist.com/2012/04/20/apis-are-forever,-wait-no...they-can-go-away-at-any-time/index.php#.T5IIrH2siH8.hackernews
======
DHowett
This makes me think of the not-so-recent deprecation of Offline Access by
Facebook. I do not know whether it will be supported ad infinitum, but if not,
it requires other completely-functional apps to be majorly rearchitected or
break entirely.

There is rarely a good reason to actively destroy old API - section it off,
keep it out of new code, maybe even kill the documentation so new developers
don't use it, but it's bad business and downright disrespectful to the third-
party developers who enrich your platform.

------
dirkdk
as I have tried to start a business building on top of API's, this is in
general a risky business. Not only can they disappear, but also work
incorrectly, go down, change overnight without notification. Also your access
can be shut down just because of a change of heart on their side

If you don't pay for access and have some kind of contract (Twitter firehose,
Bing API), yes your business goals are not aligned and you'd better prepare
for the worse.

~~~
cpeterso
Did you design your software or business plan with an API contingency plan?
Some web APIs have reasonable replacements, but most offer some unique value.

------
kijin
Clear deprecation policies are great, but I also think that every public API
needs to be explicitly versioned. This is commonly achieved by including the
version in the URL (api.example.com/v3/whatever), but a suitable header (API-
Version: 20120420) would also work.

Once published, a specific version of an API should never change in a
backward-incompatible way, only become superseded by newer versions. Likewise,
you don't change or deprecate individual methods, you merely stop supporting
older versions. That would make it much easier for developers to keep track of
API changes.

~~~
philbo
That definitely seems like the common-sense approach. There was an interesting
article posted on here recently though, which argued that API versioning is an
anti-pattern.

It makes some good points, although I'm not sure I entirely agree with the
conclusion drawn, since it places all of the responsibility on the authors of
the client-side code:

[https://secure.designinghypermediaapis.com/nodes/bujxbmhffep...](https://secure.designinghypermediaapis.com/nodes/bujxbmhffepq)

~~~
tommi
I agree on the disagreement. On removing functionality:

"This can be handled in the opposite way we dealt with new functionality: if
you don't see something, don't display it."

In my experience that is just too simplistic idea to cover all cases hence the
need for versioning.

------
hartleybrody
This is one of the best arguments for scraping data, if you can manage it.
Generally businesses invest much more time and resources into maintaining an
up-to-date, usable website than they would on an API, especially if they don't
use a service-oriented architecture internally (ie, consume their own API)

~~~
rollypolly
What type of business can afford being down every time the site they're
scrapping is tweaked?

~~~
hartleybrody
How often do websites _really_ change the layout of their DOM? Sure, some
sites that are actively developed (ie social networks) but for a lot of
business websites where information doesn't change that often, like
restaurants, reviews or clothing, websites are pretty consistent.

Plus, building a parser isn't always that much more work than trying to build
a client for a convoluted API.

It's obviously case-by-case, but I think a lot of people dismiss scraping
outright when there are a lot of useful applications.

------
tantalor
Programmable Web noticed this last year when Google started charging more for
their older APIs. Why kill the API when you can make as much money as you want
from its users?

> Google is also providing developers a reason to finally move their maps off
> of Google Maps V2. Overages for the old version of Google Maps costs $10 per
> 1,000 map views.

[http://blog.programmableweb.com/2011/10/27/google-maps-
usage...](http://blog.programmableweb.com/2011/10/27/google-maps-usage-fees-
how-many-developers-will-have-to-pay/)

------
majmun
How does one build a software that will not deteriorate over time, if he uses
unstable API?. I don't know. Just don't use unstable API if you don't have to.

