Most days you check the weather, split a bill, or let a maps app tell you which platform your train leaves from. None of those apps know the temperature, hold your bank balance, or run the trains. They ask something else, and something else answers. That conversation in the middle is an API — an application programming interface. The name sounds formal; the idea is ordinary. One program asks another for exactly what it needs, in a format both sides agreed on in advance. This walkthrough covers what that means in practice, and it ends with you making a real request to a public API in your browser.

A Menu, Not a Kitchen

Picture a restaurant. You do not walk into the kitchen and start opening cupboards. You get a menu, choose a dish, and a waiter carries the request back. The kitchen can replace its oven, hire new cooks, or change suppliers, and your ordering method stays the same, because the menu is the contract.

An API is that menu. It lists what you can ask for, what each request needs, and what you get back. The kitchen is the server, the database, and all the messy logic behind it. That separation is the whole point: the people running the service can rebuild everything behind the wall without breaking the code you wrote against the menu.

What an API Actually Is

Strip away the vocabulary and a web API is a set of rules for how two pieces of software exchange information. Almost all of the ones you will meet use HTTP, the same protocol your browser uses to load pages. You send a request to an address. You get a response back, usually as JSON.

The parts of a request

• Endpoint — the address you send to, like https://api.example.com/weather
• Method — the kind of action you want. GET reads data, POST creates something, PUT or PATCH updates, DELETE removes. As a beginner, GET is nearly all you need.
• Parameters — the details of your question, appended to the URL after a question mark.
• Headers — metadata about the request. An API key often travels here.
• Body — extra data, used mainly with POST and PUT.

The parts of a response

Every response starts with a status code. 200 means fine. 404 means that address does not exist. 401 or 403 means you are not allowed in, usually because a key is missing or wrong. 429 means you are asking too often. 500 means the server broke, and it is not your fault. After the code comes the body: the actual data.

Try One Right Now, No Code Needed

GET requests are just URLs, so your browser can make them. Open a new tab and paste this in:

https://api.open-meteo.com/v1/forecast?latitude=52.52&longitude=13.41&current=temperature_2m

Press enter. You will get a wall of text that looks roughly like this:

{"latitude":52.52,"longitude":13.41,"current":{"time":"2024-05-01T12:00","temperature_2m":18.4}}

That is the weather in Berlin, sent by a free service that asks for no key and no signup. Change the latitude and longitude numbers to your own coordinates, reload, and the number changes. You have just consumed an API.

1. Read the URL from left to right. The part before the question mark is the endpoint.
2. After the ? come parameters, separated by &. Each has a name, an equals sign, and a value.
3. Notice that you asked for one thing — current=temperature_2m — and got back exactly that. Most APIs let you request a narrow slice instead of everything they hold.

Reading JSON Without Fear

JSON is a way of writing structured data as plain text. Two symbols carry most of the meaning. Curly braces { } hold an object: a set of named values. Square brackets [ ] hold a list of things in order.

So "temperature_2m": 18.4 is a key and its value, joined by a colon. To pull a single number out, you walk the path from the outside in. In the response above, the temperature lives at current, then temperature_2m. That is the whole skill. Once you can trace a path through nested braces, JSON stops looking like noise.

Doing the Same Thing in Code

In Python, with the requests library installed, the same call looks like this:

import requests
url = "https://api.open-meteo.com/v1/forecast"
params = {"latitude": 52.52, "longitude": 13.41, "current": "temperature_2m"}
response = requests.get(url, params=params)
data = response.json()
print(data["current"]["temperature_2m"])

Two habits matter more than the syntax. Check response.status_code before you read the body, so a failure does not masquerade as data. And print the whole response once while you are learning — guessing at a structure wastes more time than looking at it.

If an API needs a key, keep it in an environment variable rather than in the source file. Keys pasted into code that ends up on GitHub get scraped quickly.

Mistakes Beginners Make

• Treating every response as a success. A 404 body often looks like perfectly valid JSON.
• Calling the API on every page load instead of caching the result for a few minutes.
• Ignoring rate limits, then wondering why requests suddenly fail. Read the docs before you write a loop.
• Building against an endpoint marked beta or deprecated.
• Assuming the shape of a response instead of reading the documentation, which is the menu for the API in front of you.

Where to Go From Here

Pick something small and finish it. A script that prints tomorrow's weather. A page that shows a random post title. https://jsonplaceholder.typicode.com/posts/1 returns fake data with no signup, which makes it a good sandbox for practicing without worrying about quotas.

Then follow the same loop every time: read the documentation, make the request by hand in a browser, inspect the JSON, and only then write code. Add error handling for the codes you actually saw, and log the raw response while you build.

You do not need to memorize endpoints or methods. The skill is reading a menu you have never seen before and ordering confidently. That comes with a few afternoons of poking at real APIs, and it stays with you.

Photo: Brett Sayles / Pexels