API stands for Application Programming Interface. Put simply, APIs are a way for a device, software or website (these are known as “clients”) to talk to a server. Think of it as a standard for how systems talk to one another. In tech lingo, this is sometimes called a communication protocol.

As we move into examples, there are a few terms you’ll need to remember:

• Client: A device, software or website
• Server: A piece of hardware that does things like store data and perform complex computations

The Great API Analogy

APIs can be thought of as intermediaries, kind of like waiters in a restaurant. To bring this analogy home, let’s imagine APIs are literally waiters at a local cafe. Remember those terms I asked you to learn? You’re gonna need ‘em.

Customers (clients) never communicate with the chef (server) directly. We have the waitstaff for that (APIs). And this is probably a good thing. Chefs are too busy to talk with every hungry customer. Even if they could, there is still the issue of communication. Customers (clients) can speak a variety of languages, or they might ask questions in convoluted ways. Thankfully, the waitstaff (APIs) know how to quickly communicate orders to the chief (server). This means faster service and happier customers. If the waitstaff (APIs) didn’t exist, it might take a very long time to fill an order.

But whereas the waitstaff take requests for food and drink, APIs take requests for information. It goes a little like this:

1. APIs take a request from a client. Something like “check for new emails” or “open a new tab.”
2. The API retrieves the requested information from the server (This part is invisible to you, the user).
3. The API returns the requested information back to the client (i.e. “no new email”) or triggers an action (like opening a new Google tab in your browser).

When Are APIs Used?

APIs are only necessary when a client (i.e. a device, application or website) doesn’t have direct access to the information it’s requesting. For example, if you were buying concert tickets directly from a concert hall, the venue has access to all of its own information. The venue’s website knows which seats are sold and which ones are available. It knows the dates of the concerts and the price for each ticket. So if you went to the concert hall’s website and purchased tickets, no API would be involved. However, if you went to a third-party site—say, one that found the best deals on concert tickets—that site would not have direct access to the specific venue’s information. In order to get show info from a given venue, the third-party site would need to access that venue’s API.

A Quick Example

Let’s say you want to check the weather using a hypothetical app called Weather Button. You press your finger to the Weather Button app icon, which triggers the app to open. But before the app loads on your screen, something happens behind the scenes. The act of tapping that icon triggers the app to request the latest weather update. The API (the intermediary) delivers this request to the Weather Button server. The Weather Button server provides the latest weather data to the API, and the API, in turn, provides this info to the Weather Button app. All this is done in the blink of an eye, thus allowing you to see whether or not you’ll need to run back inside and fetch your umbrella.

At InterWorks, we want to support you in success by connecting you to the right solutions (kind of like an API does), and we’re unique in that we’ve got both metaphorical waitstaff and chefs ready and willing to team up with you. If you’re curious about how we can actively partner with you in your work, reach out today.