On Dangers of Prematurely Making API Public

From time to time, I come across a statement that every service on the Internet must have an API, or people behind this service are doing it wrong. This phrase usually applies specifically to publicly available API.

As a user who stands to benefit from increased number of services allowing third-party applications and mashups, I certainly tend to agree. But as a developer, I realize that prematurely making API public may be a disaster.

Publication of API represents a long-term commitment. You as a developer are committing to supporting this API for some non-trivial amount of time (at least 12 months I would imagine) and are essentially inviting other developers to create new functionality against this API. No one likes to spend their time developing against a given API just to discover shortly that API changed, or some functionality that used to be offered is no longer available.

By making your API public you are signaling that this part of your system is very stable, its functionality well established, understood and developed, usage patterns well thought out. Or at least that's how I as a third-party developer interpret your action.

If you know your audience well enough and are pretty confident that they won’t mind your tweaking things after initial publication, you may take a risk. Twitter famously launched their API very very early, and in the end it proved a huge success for them. (So if they listened to my advice in this post, they would be worse off).

But not all developer audiences may be as agile and forgiving as Twitter’s. I can imagine a very conservative big user of your API that will very strongly object to your changing the API. What do you do next? Maintain 2 versions? But what if underlying database schema changes make old API incompatible with what you are trying to do in the future? Fork and host 2 different systems, old and new? I can’t honestly imagine a worse scenario.

My advice - before publishing your new API, make sure you are not going to force yourself into a corner down the road. Only publish API for those parts of your systems that are very stable (both operationally and from perspective of internal mechanics and functionality) and where usage patterns are well researched and predictable to a certain extent. Don’t rush it.

Categories: software-engineering |

Comments (3)

Marty // 06 Feb 2010

I came across your blog via searching for bloggers in Chicago. I came across your site, and while I am not a software or application developer I found the article very clear and helpful.

As I grow my own understanding of basic web mediums like blogging, I find it more important for me to understand how these apps work. It helps me with my work flow, and makes blogging, etc... more enjoyable.

Thanks for the perspective, and I'll be back.


Thomas Lukasik // 16 Feb 2010

This is very timely -- and especially relevant, as Google is daily trying to fend off complaints from developer's on the Boogle Buzz API Group about their not releasing a full API at the same time that released Google Buzz.

Brett Hoffman // 22 Mar 2010

You've made some very good points here and I agree with you on alot of them. I'm not a developer, but was researching about risks of APIs and this helped considerably.