Client and Server — How APIs Talk to Each Other

What You'll Learn

• What the words client and server mean in an API context
• What each side is responsible for during an API call
• Why the split exists and what breaks if you blur it
• Real examples of clients and servers you use every day

Why This Matters

Every API conversation has exactly two sides: a client that asks, and a server that answers. If you do not know which side you are on, you will misunderstand errors, build the wrong tests, and choose the wrong tools. This lesson makes the split unambiguous.

Simple Explanation

In an API conversation:

• The client is the program that sends a request.
• The server is the program that receives the request, does some work, and sends a response.

That is the whole model. Two programs, one request, one response. Everything else in this course is detail about how the request and response are formatted.

Real-World Analogy — Calling a Friend

Think about calling a friend on the phone. You are the client — you initiate the call, ask a question, and wait for an answer. Your friend is the server — they receive your question, think about it, and respond. The phone network is the channel that carries the conversation. The conversation cannot start unless you call — your friend does not spontaneously call you to ask "what do you want to know?"

APIs work the same way. The client always initiates. The server waits and responds. The server never calls the client out of the blue (with one exception: webhooks, which we cover in lesson 51).

What the Client Does

1. Builds the request — decides which endpoint to call, which method to use, what parameters to send, what body to include.
2. Sends the request over the network (usually the internet).
3. Waits for the response — typically with a timeout, so it does not wait forever.
4. Reads the response — checks the status code, parses the data, and decides what to do next.

Examples of API clients

• Your browser when you visit a website (it calls APIs to fetch content)
• The Postman app on your laptop
• A cURL command run from your terminal
• A JavaScript fetch() call in a web app
• A Python script using the requests library
• Your phone's banking app fetching your balance

What the Server Does

1. Receives the request from the network.
2. Validates it — checks the URL, the method, the headers, the body, and the authentication.
3. Does the work — looks up data in a database, runs business logic, calls other APIs if needed.
4. Builds the response — a status code (success or error), headers, and a body (usually JSON).
5. Sends the response back to the client.

Examples of API servers

• The Open-Meteo weather service we called in lesson 01
• Twitter's API server (returns tweets when you ask for them)
• Your bank's API server (returns your balance after authenticating you)
• A REST API you build yourself using Node.js, Flask, or any backend framework

The Request/Response Picture

  Client                     Server
    |                          |
    |  --- HTTP request --->   |
    |                          |  (validates, does work,
    |                          |   queries database)
    |   <-- HTTP response ---  |
    |                          |
    |  (reads status, body)    |

The arrow always goes request → response. The server never sends a response without a request first.

One Program Can Be Both

This is the part that confuses beginners: a program can be a client in one conversation and a server in another.

Example: a food delivery app's backend. When your phone (client) asks for the menu, the backend is the server. But when that same backend asks the payment gateway to charge your card, the backend is the client, and the payment gateway is the server.

The words "client" and "server" describe roles in a specific conversation, not fixed identities of programs.

Common Mistakes

1. Thinking the server pushes data to the client. In standard HTTP APIs, the client always initiates. If you need real-time push, that is a different protocol (WebSockets or webhooks — Module 12).
2. Confusing "client" with "user." The user is a human. The client is a program. The user uses the client; the client calls the API.
3. Assuming the server always succeeds. Servers fail, return errors, time out, and misbehave. A good client handles every case. We cover error handling throughout Modules 6 and 14.
4. Forgetting that the server has no memory of past requests (in REST APIs). Every request must contain everything the server needs to understand it — including authentication. We cover this in lesson 16 — REST principles.

Practical Exercise (5 minutes)

For each of these scenarios, identify which program is the client and which is the server:

1. You open a weather app on your phone. The app shows the current temperature.
2. A Python script downloads today's stock prices from Yahoo Finance.
3. Your browser loads a YouTube video page.
4. The YouTube backend saves your watch history to a database.

Answers: (1) Client = phone app, Server = weather API. (2) Client = Python script, Server = Yahoo Finance API. (3) Client = browser, Server = YouTube API. (4) Client = YouTube backend, Server = database. Notice the YouTube backend is a server in (3) and a client in (4).

Mini Challenge

List every app on your phone's home screen. For each, write down one server it probably talks to. (Example: Gmail → Google's mail servers. Uber → Uber's location and pricing APIs.) You will be surprised how many APIs every app touches.

Key Takeaways