TL;DR - APIs are the communication interfaces for web services. They receive data requests, process them, and send data back in response. If you've booked hotels or tickets online, you've almost certainly gone through an API. ⚙️
Prefer this in audio format? Listen to this blog post on Racket.
As I prepare to start my new role with Postman, I'm encountering a hurdle that I haven't encountered for many years: how to explain my new job to my friends and family.
My preceding trio of roles have been with three of the largest names in the UK's price comparison and housing sectors: MoneySupermarket, Zoopla and Compare The Market. So when people ask me "where are you working these days?", the name recognition alone has made it easy for people to understand the sector that I'm working in, even if they're not technologically-minded.
As for Postman? Well, they've got huge prestige among those already in the technology space, but if you're a typical person on the street - or, let's say, my 95-year-old grandfather - the sentence "it's a platform for authoring and testing APIs" doesn't mean a great deal to them. (Let's skip straight past everyone's first response, when they think that I've taken a job with the postal service.)
APIs, in brief ⏳
I was going to start by describing API as "the building blocks of web communication", which is accurate, but remains largely meaningless to the wider world. So, maybe it's easier to provide a worked example.
When you're browsing the web (or performing other web-connected actions, such as using a mobile application on your phone, or even using an ATM) then you usually interact by pointing to things and clicking on them. This action sends a data request to a webserver, comprising the pertinent information that you requested. Suppose you're on a cinema website, and you ask for Luton's cinema listings for 21st July. The request might include values
The webserver then sends back a data response, providing the information that the user requested. In this case, all of Luton's cinema data for 21st July.
If you'd asked the website for a different cinema, on a different date, the website creators don't need to write more code for that. The site just sends another request to the same endpoint (a fancy name for a web address within an API), but with different
Congratulations, you've just seen your first example of what an API can do!
Why would I build or use an API? 👷
To answer this question, let's look quickly at the history of the internet, through Web 1.0 and Web 2.0, to Whatever-Web-We're-On-Now.
Let's take our cinema example again. In the earliest days of the web, you'd probably have built what's known as a "static web page" for each day's listings at each cinema. (If you have 7 days' listings, and 100 cinemas, that's 700 webpages to write by hand… ouch.)
Fast-forward to the late 90s, and web-based database systems like SQL (don't ask) are now prevalent. At this point, websites are functionally very similar to API-based systems, but communicating with databases is a dangerous and complex business. (In general, it's a good practice to separate your web and database code as much as possible; otherwise, if hackers manage to get into your web code, they automatically get the keys to your database, and all of your sensitive customer data. Not good.)
Some sites are still coded this way; for some sites, this is still fine.
APIs aren't new, but they're certainly more popular than ever, for some key reasons:
Security. When you make a request to an API, if the data requested is sensitive (for instance, a customer's banking details) then the API will use some form of authentication (many types are available) to check that the request is coming from somebody who's allowed to view that data. If they're not permitted, they won't get the data, meaning that everybody can sleep a little bit more soundly (or become a bit more complacent, but that's another story).
Simplicity. Because of the above, the website now doesn't need to know anything about the database which the data resides in; this means your code can be more focused on displaying the data, and less concerned with how it gets the data in the first place. When maintaining large-scale websites, less code is generally a good thing.
Future-proofing. Suppose your API is loading data from a SQL database, but your organisation decides it wants to shift its data storage into a NoSQL database such as MongoDB (I said, don't ask). In the Web 2.0 world, you'd have to write (and test) a chunk of your application code in order to support this change. If your application is getting data from an API, the application doesn't need to change at all (generally). You'll need to modify the service which pumps data into the API, but as long as it's providing data in the same format as it did before, the website doesn't care where it comes from.
Microservices and the Internet of Things. Honestly I'm not going to get deep into this today, because if you've got this far then you've done well enough. But suffice to say, if you've got data that's being transferred to and from an API, then it doesn't necessarily need to be your website that's asking for the data. All of a sudden, anything that's web-enabled could be configured to get this data. Your cinema could create an Alexa skill, and a mobile app, and they could both get their data from the same API. You could even program your 'Now Showing' screens in the cinema itself to get that data in real-time from your API. This is the so-called "Internet of Things", and it's equal parts complicated and scary - but never dull.
So where does Postman come in? ✉️
In brief, Postman lets you perform requests and responses on APIs, which is very useful when constructing an API, or if you're testing to make sure your API works. Postman contains a host of collaboration tools to empower teams in constructing APIs, including the ability to "mock" how they behave (this means that you can simulate what data they would send and receive, even before you've written the code to do it).
If you've got this far, give yourself a pat on the back and pour your choice of tea or coffee. If this was genuinely your first introduction to the world of APIs, I'd be interested to hear whether it was understandable, or whether there's anything important that I've missed out. As someone who's been working with APIs daily for the best part of a decade, it's easy to take a lot of this for granted - I hope it's been of some help.
If you're feeling bold, below is the first video in a YouTube series from Postman guru Valentin Despa, which I didn't watch before writing the above - it might be fun to compare and contrast what we've said! 😆