I think we can all agree that our technical world has changed. Traditional system administrators and engineers used to "rack 'n' stack" servers, switches, NAS devices, and maintain beautiful cable management. Over time, newer gear would replace the older gear, so we were always trying to keep up with the latest and greatest gear knowledge. We all collectively hung out in the world of installation wizards, where we'd select "Next", then "Next", then "Next", and software would magically install. The "boxed product" era of IT was definitely fascinating, but prone to errors, misconfigurations, and it became hard to scale (unless you had one really large IT department).
I joke in a lot of my speaking engagements that if you approached me 15-20 years ago, told me people would trust the cloud, I'd be working at Microsoft, and I'd be hitting APIs like developers, I don't think I'd believe you...and yet...here we are! What a world!
Technical skills have been dramatically altered with the cloud taking hold of most enterprises and small to medium businesses. Offloading the burden of support for apps and infrastructure (or sharing that burden) seems like a much more attractive reality than possibly dealing with equipment failure and unforeseen outages.
Take me for example. I haven't touched physical equipment for my job since 2015. I can remember the task: updating our ESXi hosts' firmware, before moving on to a new role.
As much as I'd like to not be a developer, my skillset has change exponentially since 2015. I struggle with commas, quotation marks, and brackets, just like my developer colleagues. I get errors that aren't super descriptive and spend time on Stack Overflow or consulting online blog articles for help. The biggest hurdle I've overcome is I no longer get anxiety attacks when I stare at line of code, which is HUGE!
My goal over the next few posts will be to demystify APIs for folks who are like me. No, I don't think you'll be setting up your own APIs after understanding some of this better, but I do think you'll be more relevant when building or troubleshooting applications during this great digital transformation era we're in.
So, what is an API? When I was digging into this more for a topic I presented on last year (I'll link to the final video I recorded for a VMware vBrown Bag session at the end of these posts), I landed on the Wikipedia Definition, which was sort of helpful and sort of not helpful at the same time:
“A particular set of rules and specifications that a software program can follow to access and make use of the services and resources provided by another particular software program that implements that API. It serves as an interface between different software programs and facilitates their interaction, similar to the way the user interface facilitates interaction between humans and computers. An API is implemented by applications, libraries, and operating systems to determine their vocabularies and calling conventions and is used to access their services.”
As I read and reread through this definition, I kept thinking "this doesn't exactly make sense to me" and "is there an easier way to describe this?" Determined to break it down for my own edification first, I went down the rabbit hole and will save you from going down the same rabbit hole.
The acronym stands for Application Programming Interface. To me, that didn't really demystify the terminology and the definition above didn't help, so I built out a good analogy that I used during my talk last year: think of an API as a waiter at a restaurant. If you search online, I'm definitely not the first one to come up with this analogy, but I do think I can add some additional light to the situation. Let me walk you through my analogy (and visual) in the following paragraphs.
Let's say you go into a restaurant and want to try something new, based upon a friend's recommendation. This actually happens to me quite often, since I live in Chicago. In this analogy, you are the program. At a restaurant, you want to order food from the kitchen (because where else would you order food from, right?). The waiter, who is the API for all intents and purposes, approaches you to take your order. The waiter will jot down your order + any special instructions. The waiter then goes to put your order in for the dish (information) you requested. The chefs then prepare the meal you requested (think of this as the "back-end", maybe it's a database). When ready, the food is left in an area where the waiter can bring the food back to you so you can enjoy.
The API greatly simplifies the task at hand, so you don't have to interface directly with any system behind the API for information. You may not understand how to put an order into the ordering system, the chefs may have vernacular or terminology you're unfamiliar with related to how the dishes are prepared, and the chefs may not understand what you're ordering either, as the waiter might interface with you differently to make the process smoother. The analogy holds and it vastly simplifies an overall understanding of what an API technically is to maybe a 6-year-old.
I thought I'd include the graphic I used for my presentation. Once I landed on this metaphor, APIs made sense (finally). Of course, I've massively broken down all the specifics so you could join me in on this adventure of me explaining what I've been learning in my quest to understand development ideas a whole lot better. My intent over the next series of blogs is to demystify APIs a bit if you're curious. I've been meaning to write down some of my learnings because I'm sure I'm not alone as I venture down this path of understanding development ideas and techniques a bit better! Also, this will be great material if you've skipped your computer science degree (like I did)! ;)