What is an API, really?

There's a small kenkey spot near my old university where you walk up to the counter, look at the board, and say what you want. "One ball, fish, light pepper." The woman behind the counter nods, disappears into the kitchen, and a minute later hands you a plate. You never see the fire. You never see the grinder. You don't know which bowl she scooped the pepper from. None of that is your job. Your job is to read the board, place the order in a way she understands, and accept the plate she hands back.

That is exactly what an API is.

I'm putting this post up because every term, the moment we get to Week 3, someone messages me saying "I followed the code but I still don't get what an API actually is." The code isn't the problem. The mental picture is. So before you touch a single line of requests.get(...), I want you to carry the right picture in your head.

The counter, the menu, the plate

An API — Application Programming Interface — is a service somebody else has already built, sitting on a computer somewhere on the internet, that you are allowed to talk to.

Think of it as a counter:

• The menu is the list of things you're allowed to ask for. The API's authors decided what's on it. You can't order banku from a kenkey spot, and you can't ask the weather API for exchange rates.
• Your order is the request. You phrase it in the format they expect — usually just a specific URL.
• The plate is the response. They hand back data in a shape they've already told you to expect.
• The rules of what you can order, and what comes back — that's the API contract. It's written in their documentation.

You don't need to know how the kitchen works. You don't need to know what language their code is written in, what database they use, or whether the cook is in Lagos or London. You read the menu, place the order, accept the plate.

That's the whole idea. Everything else is detail.

Why this matters more than you think

Without APIs, every program you wrote would be limited to data already sitting on your laptop. Want tomorrow's weather? You'd be flying a weather balloon. Want today's exchange rate? You'd be calling forex bureaus. Want to know how many people starred your GitHub repo? You'd be refreshing the page and counting.

With APIs, you ask somebody who already has the answer.

That's the shift. Your program stops being a closed box and starts being a participant in a much bigger conversation. The weather service has spent twenty years building models and launching satellites. You don't have to reinvent any of that. You just ask them, politely, in the format they expect, and they hand you a JSON.

The same applies everywhere. A bank built the ledger; the ATM is just an API to your account. Google Maps built the routing; your Uber app is just asking it where to send the driver. Once you see this pattern, you start spotting it in every piece of software you use.

HTTP GET, in one sentence

The most common kind of API call is an HTTP GET. One sentence: you are asking a service for something, and the URL is your specific request.

That's it. The URL is the order. Different URLs ask for different things from the same service, the same way "one ball, fish, light pepper" and "two balls, no fish" are different orders at the same counter.

In Python, it looks like this:

import requests
 
response = requests.get("https://api.exchangerate.host/latest?base=USD")

One line. You handed the service a URL. They handed you back a plate, which we've called response. Now you open the plate and see what's on it.

JSON — what they hand you back

Almost every API today hands its data back as JSON. Don't let the name worry you. JSON is just text shaped like the nested dictionaries and lists you've already been working with all course. Same shapes, same square brackets, same keys and values — they just travelled across the internet to reach you.

A weather API might hand you back something like:

{
  "location": "Accra",
  "current": {
    "temperature_c": 31,
    "humidity": 78,
    "condition": "Partly cloudy"
  }
}

You already know how to read that. It's a dictionary. The current key holds another dictionary inside it. To pull values out, you do exactly what you did in Week 2.

The one new step is asking Python to turn the response into that dictionary for you:

data = response.json()

.json() takes the text the server sent and parses it into a real Python dictionary you can index into. After that line, data behaves like any other dictionary you've made yourself.

A small worked example

Let's do the whole thing end to end. Four lines. We'll ask the exchange rate service what one US dollar is worth in Ghanaian cedis, and print it as a sentence you could text your mum.

import requests
 
response = requests.get("https://api.exchangerate.host/latest?base=USD")
data = response.json()
rate = data["rates"]["GHS"]
 
print(f"One US dollar is currently worth {rate} Ghanaian cedis.")

Read it slowly. Line by line, this program:

1. Walks up to the counter at api.exchangerate.host.
2. Places an order: "latest rates, with USD as the base."
3. Accepts the plate.
4. Opens it up as a Python dictionary.
5. Reaches into the rates key, then the GHS key inside it.
6. Prints a sentence a human can read.

That is a real program. It pulls live data off the internet and turns it into something useful. And there is nothing in it you didn't already know — dictionaries, indexing, f-strings, and one new function call.

Take this with you

The reason APIs feel mysterious at first is that we picture them as magical. They aren't. An API is a counter. Somebody built the kitchen, wrote a menu, and put it on the internet. Your job is to read the menu, place the order in the right format, and unpack the plate they hand back. Everything you'll learn this week — status codes, headers, error handling, API keys — is detail on top of that one picture. Keep the counter in your head, and the rest stops being scary.