API Exposure
I tried to make a mental note of how many APIs I used yesterday. I gave up by lunch.
The morning started with iPhone’s weather app, I needed to know if I should bring a rain jacket with me on the dog walk. The Weather Channel’s API says clear skies, all systems go. Next, Nellie (my dog), remarkably quick on the uptake, is jumping up and down while I fumble to get my headphones on and pull up Spotify. There’s two.
So, before we get too far into my day-to-day routine, let’s nail down some fundamentals about APIs. An API (Application Programming Interface) is an intermediary between two separate applications.
Ever wonder how your frisbee golf app (I assume you all are avid frisbee golf enthusiasts) has access to today’s weather in the specific park you happen to be playing in? It’s accessing an API– probably the same API your phone uses (through Weather.com). It’s also a safe assumption that you’ve shared your location with the app at some point so it may offer recommendations for the most pristine courses nearby (I admit, I’ve done this when traveling out of town before). This is yet another API my frisbee golf app is accessing.
Think of it like this — in order for your apps to function at their full capacity, they rely on outside resources in order to gather enough information and data to reliably inform you, the customer, on what it is you may need. The same way a journalist would when reporting a story.Google and Apple, as almighty and powerful as they are, do not have weather balloons posted throughout the world. They rely on experts who specialize in that information. In this way, it might be helpful to think of an API as a major part of an information network.
At the end of our little neighborhood is the coffee shop we go to in the mornings. Having forgotten my wallet, I open the (Wallet) feature on my phone, where I pay for my small coffee through Square with a swipe. There’s two more APIs hard at work this morning.
Ok, that probably makes sense, but how do APIs actually work? A quick google search will take you to any number of websites or YouTube videos that will walk you through the tried-and-true waiter at a restaurant metaphor. But seeing as how we’re at the neighborhood coffee shop, we’re going to change it up (just barely).
To put it plainly, the API takes requests, tells their database what to do, and returns that service back to you (assuming they offer that service) in a digestible package. So, at the walk-up when Nellie and I ask for a small coffee, the barista moves to the airpot and begins to fill up an agreed upon cup size full of coffee and then returns that item to me.
If you extrapolate this brief image to APIs it would look something like this: A user or web page will make a request through the internet to the API, the API will then take that request through the server and access the pertinent database, where it will retrieve the necessary information, and begin the journey back to the webpage, with a timely and adequate response.
On the walk back home my partner gently reminds me that it’s the end of the month. A nudge to pay rent. I send our landlord rent through Venmo and immediately begin plotting lunch. I search “Sunday crawfish” and pull the address of a local business here in town on Google Maps. I begin to lose count of my exposure to various APIs for the morning, I just assume each moment in my life when one bit of information interacts with another, there are a series of brief requests and responses firing, where information is shared, parsed, and used in conjunction with other sets of information.
