Why the “Sudden” Explosion of APIs?

APIs are not new. Anybody who’s been involved with enterprise apps knows this is true. And yet, “suddenly,” they’ve moved from a development tool to a critical component of an online or mobile business strategy.

It raises the question: Why did API use “suddenly” explode?

David Zhang addressed the question of why APIs have risen to such importance in a recent blog post:

“The raise [sic] of API is more about a new way of doing business than another programming paradigm. In web apps, an API is as much BizDev as actual Dev, and any company that wants to have anything to do with APIs needs to understand this.”

Zhang is a self-professed entrepreneur. I say “self-professed” not to be disparaging — I’m sure he’s a very smart young man — but because Tigervine, the web-based software company he founded with two college friends, is actually still in beta.

I hate to pick on Zhang — because he’s getting enough of that on Hackernews, where he invited comments — but his logic here is circular. It boils down to “APIs are a way of doing business and so they are adopted by the business.”

While it’s true that APIs represent more of an evolution in business partnerships than in technology, it still begs the question: What changed? Why did APIs shift from a proprietary tool for enterprise apps to a core part of any online or mobile business strategy?

I actually researched and wrote about this in 2009 for IT Business Edge, after one of my editors pointing out that he was “unimpressed” by open APIs since APIs have been around for a long time.

I learned there were actually three trends that shaped the rise of APIs as a strategic tool for opening up data and services:

  • The evolution of service-oriented architecture (SOA) and then web-oriented architecture.
  • The web’s concept of “open” and connection. Web companies, starting with eBay and then Amazon, quickly saw that they could take the concept of web services and expand their business by opening up some of those services as APIs. It was a natural extension of the philosophy of SOA: Agile and re-usable — but with a Web twist. These APIs were called beOpen APIs to differentiate them from the closed, proprietary APIs used by traditional enterprise applications.
  • The adoption of REST and JSON. While SOAP can and is used for developing Web services and APIs, it’s more complex than REST. By 2008, REST had established itself as the leading protocol for APIs, followed by SOAP (22 percent) and JSON (7 percent). That gap, by the way, has only grown.

It’s worth noting, too, that the growth of API adoption was neither sudden nor did it happen because "everyone" saw that APIs were business-friendly. While web companies embraced APIs quickly after the public success of eBay’s and Amazon’s APIs, traditional businesses and enterprises were actually slow to warm up to open APIs. As Dion Hinchcliffe, who first described web-oriented architecture and the importance of open APIs, wrote in 2008:

"Business leaders are much more likely to understand investment in a traditional Web site, which they are familiar with and understand somewhat, than in an online software development kit, which is more developer-centric and which they are much less likely to fully appreciate, even though APIs can often have more strategic value than a Web site."

Keep in mind there were only 1,000 open APIs registered at ProgrammableWeb at this time.

As open APIs grew in number, we’ve tended to drop the “open” and just say API. That’s a fair change, since some APIs are not, in fact, open, but more of a hybrid that offers access for a fee.

Still, even though a lot of the details are off or missing, Zhang’s his main message is correct: “When you’re working with a company’s API, you are working with the company as a business partner.”

And like most partnerships, it’s for better or worse, as his readers on Hack News so adamantly point out.

Be sure to read the next API article: MetricFire Provides Application Metrics-as-a-Service