What is an API?

If you’re a regular viewer here, you’ve likely heard the term “API” plenty of times, but if you’ve clicked on this video there’s a good chance you aren’t quite sure what that actually is. Let me explain. For the TikTok generation, an API is an application programming interface, and it’s the way computers talk to each other. You can swipe on now if you don’t want the extra information. For the rest of you, well first thanks for sticking around, and second, let me explain more.

API’s are everywhere, from AI to Amazon, with some being more visible than others. Every website you go to that requires you to log in has an API that you’ll never see (unless you look in dev tools anyway), but some are very public. If you’ve looked at Ollama, for example, you know there are only two ways to talk to an Ollama model, either via the terminal, or via their “API”. Websites often offer free or paid API access, with a few controversial examples from recent memory being Reddit and Twitter – but what does it actually mean? Well an API is generally a web thing, where the data is all sent over network protocols. You can have local APIs – Ollama is actually a good example for that as you basically send a request to port 11434 on localhost and it returns a response, but that’s basically the same process for internet based APIs. 

Let me distinguish the difference between public and private APIs quickly. Websites that let you sign in, buy stuff and generally are anything more than a static landing page all have a backend, AKA an API. Modern websites are built with two main parts, the front end, the actual web page you see, and the back end, the bit that handles loading and storing data. If you log into a website, the front end sends requests to the back end – it sends your (hopefully encrypted) password and username, and the API sends back a login token to let you in. The front end then checks for that token for every new secure page you request, and sends the token along with important requests to prove you are authenticated to make those requests. Those are private APIs – ones you won’t ever know exist, ones you can’t meaningfully interact with outside the expected application which is the website it’s tied to.

Public APIs, on the other hand, have publicly accessible endpoints, documentation on how to request data, sometimes how to authenticate yourself, and things like data limits too. This is probably what you think about when you hear “API”, like the YouTube API or Reddit API, a way to extract or enter data programmatically to another site or service. That part, programmatically, is actually really important here. Take the YouTube API, for example. You can just go to youtube and edit a video’s title by clicking the buttons, typing in what you want, and clicking save. That works, obviously. But what if you want to get the current stream viewer count for your stream deck, or your subscriber count for one of those fancy digital clock type things? The clock can’t exactly load up the website and find it (well it can, that’s called scraping but we’ll come back to that), it’d just be easier if it can just ask google “hey how many subscribers does this channel have?” and google replies with the number – and for pushing data, like updating a title with a live price of the product in the video, well again you can manually update it yourself, but it’d be a massive pain to have a computer try to load the website, then find the buttons to press, input the new data, then find the button to save. Wouldn’t it be much easier if you could just send a single request to google to say “hey change this video’s title please, to this” and google just does it and replies “no problem, done”. Well, that’s what the YouTube API is for. 

I said we’d get back to scraping, so here goes. Scraping is when you have your program load up the web page and extract information ‘manually’. This is possible, although a number of sites block non web browsers from even accessing the site outright, at least without a user agent in the header anyway, and it’s also very inefficient, and fragile. APIs generally are pretty stable. They do upgrade from time to time, especially big companies like Amazon, where there might be “breaking” changes, ie changes that break the current structure and require change on the requester’s part to make it work, but that’s somewhat rare. The front end changes more frequently. The data you are looking for might move, or change tag names, the layout might change, or if you’re entering data the steps required to do that might change, meaning you have to re-make the whole bot just to make it work again. APIs provide a ‘frictionless’ (read: easier) solution that’s more efficient, safer for everyone, and generally easier to work with. 

APIs, both public and private, are made up of endpoints. They are the specific questions you can ask the API. They can be in a couple different forms, GET requests are asking for the server to return information. Here you generally encode any request data in the URL – so when you search on amazon for something you’ll notice the URL goes from Amazon.co.uk to Amazon.co.uk/s?k=What+You+Searched – that’s because the k= is a URL parameter that the backend uses to know what you searched for to then return the items the search page displays. The other common form of request is a POST request. That’s where you provide some data to the server. Sometimes that is just sending data to the server – for example changing the title on YouTube would be a push request as you ‘push’ the title to google – but sometimes it’s used to send data that the server can then do something with and then send back. We’ll see some examples of that in a minute. It’s worth noting that there are other HTTP request types, like PUT, that you might find occasionally, but GET and POST are by far the most common. 

Let’s take a look at two free public APIs, starting with a nice simple one, DigitalOcean’s status API. Their documentation page shows that there are eight endpoints in total, although a couple of them are subsets of each other. Technically speaking this is really just a list of JSON files that DigitalOcean programmatically generates, but it’s close enough for our example. I’m using a tool called Insomnia which is a great thing for testing APIs and web development, and here I’ve got a get request set up for DigitalOcean’s main status endpoint. Sending the request returns an awfully long JSON file with the current status of every DigitalOcean service, every server region, everything. There is a lot here. But this is all easily decipherable for a program – if you wanted to do something with this data automatically, you can pretty easily. Looking at the scheduled maintenances, you can see the last 50 entries, with explanation text and everything. The incidents are the same, showing what service was affected, the status of the incident, and any identified causes. 

The other one I want to look at is a proper API, this time one called Vector Express. This is a free image conversion API with a whole bunch of endpoints – and actually an endpoint to know what endpoint to use. You’ll send a GET request to the convert file type, auto tool, and output type to get back what actual endpoint to use. In my case I want to turn an SVG into an EPS file, so I’ll run /convert/svg/auto/eps, and use the top result that uses librsvg to do the conversion. Now we need to send them the image we want to convert, so that requires a POST request with the image as the body, and 480 milliseconds later we get the converted image back. Well, we get a link to it that we can then download and open in Illustrator to see that yes, this is a properly converted EPS file, with layers and everything. 

I would guesstimate that the majority of at least public API endpoints are all GETs, fetching data from a service, be that stock market prices or Reddit posts for your third party Reddit app. It’s more rare to find especially free public POST request endpoints, because that requires sending data to the server, and that’s a lot harder to protect against. Paid APIs exist in plentiful supply too of course, but if you’re watching this video and learning stuff it’s probably best you stick to the free ones until you’re sure you aren’t going to ring up an insane API bill by accident… This is also where you might run into quotas and rate limits, where you can only send so many requests total or per minute respectively. This is mostly only a problem if you are incorporating an API into a program or website that needs to send a lot of requests to work – like Locally Links’ Amazon stock checking, for example. 

So, in short, APIs are a way for computers to talk to each other. They are made up of endpoints, which can be GET or POST requests. They can send out data, or receive it, they can be limited by total or periodic request counts, and at least when available mean you don’t need to scrap a site. They can be private, when building a website, or public, and even run locally, but it’s basically always over network traffic. That’s what an API is.