You might be wondering why I am writing an article on “What is an API” when there are many established authorities that have defined an API and done that task well. Instead, I am going to focus on what constitutes an API? And what is the difference between API and APIs? There are over 20,000 (and counting) programmable web APIs but it depends on the conversational context as to what that count really means.
Background
However, let me go back to the beginning and establish the baseline of what an API is. For this, I am going to turn to our friends at MuleSoft, a leading provider of the widely used Anypoint platform for designing, building, and managing APIs and integrations (to be transparent, XTIVIA is a long-time partner with MuleSoft and we have 100+ MuleSoft certifications amongst our team members) – they have a rather simple-to-understand definition –
API is the acronym for Application Programming Interface, which is a software intermediary that allows two applications to talk to each other. Each time you use an app like Facebook, send an instant message, or check the weather on your phone, you’re using an API.
And if you would rather watch a video that makes this more real for you, then check out MuleSoft’s video on this topic.
What Constitutes an API?
In my experience, once folks have an aha moment about “what is an API,” and they start having meaningful conversations about APIs and how APIs can accelerate their integration initiative (or might I say digital transformation?), the next stumbling block for some is API granularity. For example, does Salesforce have an API or does Salesforce have multiple APIs to connect with various other apps? Or alternately, does Twitter have an API or does it have a Twitter Ads API, Twitter Search Tweets API, and Twitter Direct Message API. I have asked this question of myself many a time and recently I asked my team. I got many answers, but the one that I liked the best came from Keith O’Connell –
It depends … I’d go with a semantic use based on what you’re talking about. If you’re talking about two separate vendors, treat each vendor’s “API” as singular; i.e. “Integrating the Box API with the Salesforce API,” but if you’re deep diving into the contents of a specific vendor, treat each target entity as a separate “API.”
Taking Keith’s input, here is what I posit –
Applying this definition to an example, you can say –
- The Salesforce API
- Or that Salesforce has a Force.com REST API, a Marketing Cloud REST API, a Pardot API and so on.
- Or that Pardot has an Accounts API, a Campaigns API, a Custom Fields API, and so on.
And for emphasis, here is another example –
- The Twilio API
- Or that Twilio has a Programmable Voice API, a Programmable Video API, and a Programmable SMS API.
- Or that the Voice product has a Call API, a Conference API, a Recording API and so on.
Now each of the object APIs support multiple operations (for example, Twilio’s Conference API supports “fetch a unique conference,” “list multiple conferences on your account,” and “update an active conference”) and some people like to think of these as APIs too. However, this is where I stop and just call them separate operations on an API.
In Closing
Hope you found this article useful and thought-provoking. I would love to hear your comments on whether you agree, disagree or that this is “much ado about nothing.”