Almost everything you use online is quietly held together by APIs. When your weather app shows the forecast, when you pay with a card, when a website logs you in with Google — an API is doing the work behind the scenes. This course explains what they are and how they're built, from zero. No experience needed.
- Understand what an API is, in plain language, with no jargon
- See how a "request" and a "response" form the heartbeat of every API
- Know the simple building blocks: endpoints, methods, data, and status codes
- Be able to read what an API call is doing, even if you've never coded
What an API actually is
API stands for Application Programming Interface. Forget the intimidating name. An API is just an agreed way for one program to ask another program for something — and get an answer back.
The classic analogy is a restaurant. You (one program) don't walk into the kitchen and cook. You read the menu (the list of things you're allowed to ask for), tell the waiter (the API) your order, and the waiter brings back your food. You never see the kitchen. You don't need to. The menu and the waiter are the interface — a clean, agreed way to get what you want without knowing how it's made.
That's an API. The weather company has all the weather data in its "kitchen." Your phone app reads the "menu" (here's what you can ask: a forecast for a city), sends an order through the API, and gets back the forecast. Your app never touches their database directly — it just asks, politely, in the agreed way.
- An API is an agreed way for one program to ask another for something and get an answer
- Like a restaurant: you order from the menu via the waiter, never touching the kitchen
- APIs let software be built by connecting existing pieces instead of rebuilding everything
The heartbeat: request and response
Every API works on one simple rhythm: a request goes out, and a response comes back. The thing making the request (your app, a browser, a phone) is called the client. The thing answering is the server.
Let's make it concrete. Your app wants details for user number 42. It sends a request that essentially says "GET me /users/42". The server looks it up and sends back a tidy answer: { "name": "Ada", "email": "ada@example.com" }. Request out, response back. That's the entire cycle, and every API — no matter how complex — is built on it.
The data comes back in a format both sides agree on, almost always JSON: a plain-text way of writing data as names and values, readable by humans and machines alike. (It's the { "name": "value" } style you see above.)
- Every API runs on a request → response cycle
- The client asks; the server answers — with data, usually in JSON
- You can make a real API request just by opening an API URL in a browser
- Using the restaurant analogy, what plays the role of the "waiter" and the "menu"?
- In "GET /users/42", who is the client and who is the server, and what comes back?
How an API is built: the four parts
When someone "builds an API," they're really defining four simple things. Once you see them, every API becomes readable.
Endpoints — the addresses
An endpoint is a web address for one kind of thing. /users for users, /orders for orders, /users/42 for one specific user. Building an API starts with deciding these addresses — your "menu."
Methods — the verbs
Each request carries a method that says what you want to do. There are four everyday ones:
- GET — read something ("get me user 42")
- POST — create something ("add a new user")
- PUT / PATCH — update something ("change user 42's email")
- DELETE — remove something ("delete user 42")
Same address, different verb, different action. GET /users/42 reads; DELETE /users/42 removes.
Data — what goes in and comes out
When you create or update, you send data in (the new user's details). The server sends data back (the result). Both travel as JSON. Building an API means deciding the shape of this data.
Status codes — did it work?
Every response carries a 3-digit status code reporting what happened. You already know one: 404 (not found). The everyday ones:
- 200 — OK, here's your answer
- 201 — created successfully
- 400 — your request was malformed
- 401 / 403 — you're not allowed
- 404 — that thing doesn't exist
- 500 — the server broke
That's it. Endpoints (addresses), methods (verbs), data (JSON), status codes (results). Every API — Google's, your bank's, the one you might build — is made of these four parts. The rest of this track is about doing them well.
- Building an API means defining endpoints, methods, data, and status codes
- Methods are verbs: GET reads, POST creates, PUT/PATCH updates, DELETE removes
- Status codes report the result (200 OK, 404 Not Found, 500 server error)
- It all rides on shared standards — HTTP and JSON — so anything can talk to anything
Putting it together — a tiny mental model
Let's trace one real interaction end to end, so it sticks. You tap "place order" in a shopping app:
- The app (client) sends
POST /orderswith JSON data: the items and your address. - The server receives it, saves the order, and replies
201 Createdwith JSON:{ "orderId": 8842, "status": "confirmed" }. - The app reads that, shows "Order confirmed!", and remembers order 8842.
Later you check on it: the app sends GET /orders/8842, the server replies 200 OK with the current status. Every feature in every app you use is, underneath, a sequence of these small, well-defined requests and responses.
- Real features are sequences of simple requests and responses
- "Place order" = POST /orders → 201 Created; "check order" = GET /orders/8842 → 200 OK
- You now have the core mental model every API builds on
- Which method would you use to create a new order, and what status code signals success?
- Name the four building blocks of an API, with one example of each.
- Why does it matter that APIs ride on shared standards like HTTP and JSON?