Should your company write its own API management solution?

May 25, 2013

TL;DR: Unless a company is explicitly in the business of building APIs (or is dealing with massive amounts of real-time data like Twitter), it really shouldn’t write its own API management solution.

API management is one of the hot topics across all industries, and for good reason: APIs provide companies with a controlled means of distributing commercial data. For those of you for whom this is a new concept, API 500’s discussion of the economy of APIs is well worth a read. The question is no longer whether an API should be built (hell, this hasn’t been the question for a while)—it now revolves about how the API should be built (and how a company can retain power over it). If you’re still not convinced, Mark Carges (an eBay CTO) mentioned that they have have sold some “$7 billion worth of items on eBay through APIs”; at Twitter, Biz Stone (one of the co-founders) stated that the “API has easily ten times more trafic than the website”.

“$7 billion worth of items on eBay through APIs"—Mark Carges

Building an API as a product (à la Twilio, SendGrid, EasyPost, Stripe, PintLabs to name a few examples) is difficult enough; building—and managing—an API to expose ad-hoc data for internal and external consumption is even more difficult. Those who build APIs as a product get to devote entire teams just to one aspect of an API. These teams will hopefully have clear requirements; the company is able to tailor teams to meet these requirements; they will know exactly what they are attempting to do and how to accomplish it; in short, their API will always be their greatest focus. On the flipside, companies who want to expose their existing data are unlikely to have such luxuries: perhaps the order to build an API has been handed down from the business managers; their development team is already strung out from quickly having to try and support the latest trends in technology; they have their data locked down in legacy services and across various sites; perhaps most importantly: providing APIs is not what they were built to do. Even companies who only provide online services find it really quite hard: LinkedIn’s initial attempt at building an API was a miserable failure, and Groupon’s API still attracts derisory comments. The issues these guys experienced (and indeed are still experiencing) have nothing to do with the quality of the data, but the stability and performance of their service. We’re not even talking about API management here, just APIs in general. What chance does a company stand of building APIs if the web is not their area of expertise?

“As a mobile app developer working in the location space and wanting to include local offers, integrating with Groupon as your deals platform was never a seamless user experience."—MobileFOMO on Groupon

Using API management software allows a company to leverage its existing technology stack and lets them control how people interact with its data. Even better: this software allows companies to do this without having to go through the headache of either a) putting together an entire software development team to build a new product from the ground up; or b) outsourcing it to a third-party company who are likely to misinterpret all of your requirements and do everything over budget and on the wrong side of the deadline. Crucially, an API management solution doesn’t simply expose data; it also helps with controlling access to the data, versioning the API and in some cases even provide a marketplace for selling the data.

If you really know what you are doing, writing your own API from the ground up and trying to manage it properly might not be an exercise in futility. But if you don’t know what you’re doing, writing your own API is probably going to screw you over. Don’t make that mistake.

Discussion, links, and tweets

I help to build IBM API Management. I also tweet a bit (but not as often as I should, and I probably talk too much about bicycles).