Like with almost any other acronym in the world, API was formed from a phrase that is generic enough to not be wrong and, at the same time, so generic that it loses all of its descriptive power, therefore, it has little meaning to most. By the way, there is already an acronym that describes this exact state: FUBAR. Unlike API, FUBAR is very descriptive and, who knows, maybe that's the reason why nobody writes articles or blog posts about FUBAR while there are so many about APIs?
Considering this, before jumping into a discussion about the purpose of APIs, I feel obligated to establish what API means (at least to me). Wikipedia says that an API "is a set of subroutine definitions, protocols, and tools, balsamic reduction, Illuminati for building the new world order". The words that I injected into this quote didn't make any difference, did they? The aggregated FUBAR score probably remains the same.
There are thousands of articles explaining that APIs enable apps "to talk" to each other. As these articles progress, they attempt to dumb down HTTP specs and REST architecture for no obvious reason except to reach a climactic catharsis by dropping something like "APIs are an innovative technology that makes a difference, transforming the world as we know it, making the world a better place through minimal message-oriented transport layers and constructing elegant hierarchies for maximum code reuse and extensibility". Depending on your preceding biochemical and neurological state, this leaves you excited or exhausted while still questioning what the heck is an API and why do we need it?
Google Trends for "API" since 2004
I'll attempt to explain what an API is without using any of these words: HTTP, REST, GraphQL, server, architecture, distributed, cloud, on-premise, secure, protocol, other SEO keywords.
APIs are a feature of an app. Just like the “follow” button in Instagram — simply another feature. The API feature allows you to add other new features to that existing app without asking the vendor to implement it. Historically, all of these features developed by third parties were called modules, plugins, extensions and most recently — apps. For example, an iPhone can't count steps or calories but it has a built-in barometer and motion processor and provides a feature (API) to access this data. Then it's up to software developers to interpret the data and build your favourite health app that counts steps and derives the number of calories you’ve burnt. If this feature (the API) hadn't been available, you probably wouldn't have a health app because the hardware manufacturers were focused on what they do best. Smartphones have GPS chips and also have a feature (API) to access GPS data. If it didn't have GPS API, there would be no Uber, Yelp or Tinder (or they would have had to spend years building the hardware and data services that they leverage to create value).
As you can see, we don't need to understand HTTPs or REST or JSON or any of those words not because I worked around them but because they are irrelevant to the purpose. Apps can live on smartphones, desktops, big powerful computers in a secret underground data center or up in the sky sitting between two rainbows (I promised to not use the words: server, on-premise, cloud).
Extending apps is not the purpose but the means by which the purpose is served. Virtually every enterprise in any industry, is becoming an IT company built around its core competency and governed by its subject domain experts to make the world a better place — for profit or not for profit.
What is true of most industries is that distribution and customer acquisition are crucial. Customer acquisition is attributed to having better services or a wider portfolio, or by being a niche player delivering a superb but very specific service to a small handful of customers. It seems just impossible to please everybody and deliver all sorts of services without overspending or sacrificing quality.
This is exactly where APIs are the answer. An API is the enabler that allows the business transformation of a service provider into a service platform. Essentially, it means that instead of trying to build a gigantic generic solution that nobody likes or a multitude of too-little-too-late solutions in-house, you can expose (and control) the building blocks (APIs) that can be used by other organizations to build very specialized high-quality solutions. This creates a rich ecosystem around the platform serving the customers. Want to count the steps you walked today? — There is an app for that. Want to make a payment from your ERP — there is an app for that. Want to request a small business loan without any hassles? — Hopefully, there will be an app for that too. Imagine a smartphone without apps — it's called Blackberry.
The real purpose of APIs actually lies in business development. Making your service available to more apps in more contexts and it is one of the most powerful distribution platforms ever built.
Paul Graham, VC and the co-founder of YCombinator (the world's most powerful startup incubator, the combined valuation of YC companies is over $80B) once tweeted:
"API= self-serve biz dev."
Many of the fastest growing startups in recent years depend exclusively (or primarily) on this distribution strategy including Stripe or Twilio.
APIs do make business development easier, but making them relevant and self-serve is an art and a science- one that we will discuss more in future articles.