What is a server? What is a client? What is HTTP?

Status: drafted · Time: 10 min · Audience: anyone-curious Outcome: Understand the request-and-response conversation behind most software.

The one-paragraph answer

A client is a computer that asks for things. A server is a computer that answers. The client is usually your phone or laptop; the server is usually a machine in a giant warehouse somewhere far away. HTTP is the language they use to pass questions and answers back and forth. That’s it. The rest of this chapter is just colour.

Picking back up where we left off

In chapter 0A.2 we said the frontend lives on your device and the backend lives on a server somewhere else, and they talk to each other over the internet. That sentence is still true — but the next time you hear someone say “the API is slow today” or “the server is down” or “the frontend can’t reach the backend,” you’ll want a slightly sharper picture of what’s actually going on.

The picture is, mercifully, simple. There are two roles. One asks. One answers. They speak a common language. That’s the whole architecture of the internet. Everything else is detail.

Client and server, in a single picture

   ┌──────────────────────────┐                  ┌────────────────────────┐
   │       CLIENT             │                  │       SERVER           │
   │  (your phone, laptop,    │ ───── asks ────▶ │  (a computer in a      │
   │   browser, app)          │                  │   warehouse somewhere) │
   │                          │ ◀──── answers ── │                        │
   │  Runs the frontend.      │                  │  Runs the backend.     │
   │  One per user.           │                  │  One serves millions.  │
   └──────────────────────────┘                  └────────────────────────┘

The two roles are roles, not types of hardware. Your laptop is a client when it’s loading a webpage. Your laptop could be a server too if you set it up that way (hint: when you run npm run dev later in White Belt, you’ll briefly turn your laptop into a server, talking to a client that’s also your laptop — it’s fine and it’s normal).

What makes something a server, in practice, is two things:

It’s reachable from far away. It has an address (we’ll come to that) and it’s listening for requests at all times.
It’s serving many clients at once. A typical production server is handling hundreds or thousands of conversations simultaneously, like a very busy waiter who can sprint between tables faster than you can blink.

Your phone is a client because it’s only ever asking on your behalf. The server you’re talking to is also talking to thousands of other phones at the same instant. That asymmetry (one server, many clients) is the shape of basically every product you use.

Where servers actually live

You’ll hear “the server” said as if it’s one thing. In reality, “the server” for any meaningful product is usually:

A handful of physical computers in a data centre: a giant warehouse full of servers, racks and racks, owned by a cloud provider.
Plus a copy of the same set in another data centre on another continent (so when one warehouse loses power, the other one keeps things running).
Plus a few tiers of caching layers in between, which exist to hand back common answers fast without bothering the real servers.

When someone says “the server is down” they almost always mean one logical server (the bit doing checkout, or the bit doing search) not the building. Buildings rarely go down. Logical-servers go down all the time, usually for reasons that have nothing to do with the hardware.

You don’t need to know any more than that. The mental picture you want is: somewhere far away, some computers are listening, they have your stuff, and they answer when asked.

How they find each other (very briefly)

When you type razorpay.com into a browser, your browser doesn’t actually know where Razorpay’s servers are. It asks a phone-book-of-the-internet called DNS (“domain name system”), which tells it the address — a number like 34.117.65.142 — that the server is reachable at. Your browser then fires off its question to that address. The address is called an IP address; the name is called a domain; DNS is the lookup that turns the name into the address.

You don’t need to retain any of that vocabulary unless you want to. The only practical reason it ever matters in an ops or product conversation is that DNS itself can break, in which case “the site is down” might really mean “the phone book is broken and nobody can find the address right now.” It’s a possibility worth knowing exists.

HTTP — the language of the conversation

So clients ask, servers answer. In what language?

The dominant language is called HTTP (“hypertext transfer protocol”). HTTPS is the same thing with encryption added (the S). Almost every website, app, and API on the internet speaks HTTP. It’s old, it’s a bit baroque, and it’s the lingua franca.

An HTTP request has three meaningful parts:

A method. A verb. The most common are GET (“show me”) and POST (“here’s something new, do something with it”). There are a handful of others (PUT, DELETE, PATCH) that don’t matter much for our purposes today.
A URL. Where the request is going. https://api.razorpay.com/v1/payments is a URL. It tells the request which server, and which piece of information at that server.
A body. Optional. The actual content of the request. A GET usually has no body — you’re just asking. A POST usually has a body — you’re sending data.

An HTTP response has three meaningful parts:

A status code. A three-digit number that classifies the outcome. 2xx means the request succeeded, 3xx redirects, 4xx means the request could not be fulfilled as sent, and 5xx means the server could not complete an apparently valid request. The family narrows where to investigate; it does not assign blame.
Headers. Bits of metadata about the response. Mostly you can ignore them; occasionally one matters.
A body. The actual answer. Usually JSON (we’ll meet JSON in chapter 0A.5) or HTML (the language of webpages).

When you load any webpage, your browser is sending dozens of HTTP requests behind the scenes — one for the page itself, one for the stylesheet, one for each image, one for each script — and stitching the responses together into the rendered page you see.

Status codes, in plain English

You’ll hear status codes used as shorthand in incident channels and in error messages. There are five standard families:

1xx — “Keep going.” The request is still in progress. Browsers and apps usually handle these responses without showing them to you.
2xx — “Completed.” Most often 200 OK. The server accepted and completed the request, though you still need to check that the returned result is the one you expected.
3xx — “Look over there.” The client needs to follow another location or use a cached response. Browsers often handle this automatically.
4xx — “This request cannot be fulfilled as sent.” Read the exact code and response before choosing a fix. 400 points to an invalid request, 401 to missing or invalid authentication, 403 to a request the server understood but will not permit, 404 to a resource that is absent or not disclosed, and 429 to too many requests. A 4xx does not prove that the user made a mistake: an expired token, changed permission, stale client, or rate limit can all produce one.
5xx — “The server could not complete this apparently valid request.” 500 is the generic unexpected-failure response; 503 usually means the service is unavailable. The cause may sit in the application, a dependency, a proxy, or overloaded infrastructure. The family tells you where to start, not which team to blame.

When the dashboard is misbehaving and an engineer asks for the status code, give them a small evidence receipt:

Operation: <what you clicked or requested>
Status: <exact HTTP status>
Response: <exact non-secret error text>
Time + scope: <time and timezone; only you or multiple users?>
Retry: <not tried / same result / different result>

That receipt separates authentication, permission, rate-limit, application, and dependency failures much faster than “it threw a 4xx.” Status codes are routing clues, not a courtroom verdict.

A worked example

You open your phone. You tap your bank app. Here’s roughly what happens, with names:

The app (the client) makes an HTTP GET request to https://bank.example.com/api/v1/balance. It includes a header that says “I am this user, here’s my session token.”
The request travels over the internet: through your phone’s cell tower, through a chain of routers, eventually arriving at one of the bank’s servers in a data centre.
The server reads the request. It checks the token (is this really you?). It queries its database (next chapter — the spreadsheet that has everyone’s balances). It computes the right number for you.
The server sends back an HTTP response. Status code 200 OK. Body: {"balance": "12345.67", "currency": "INR"} — that’s JSON, the most common shape of HTTP response bodies these days.
Your app receives the response, parses the JSON, takes the 12345.67, formats it as ₹12,345.67, and renders it on the screen.

That whole conversation happened in under a second. It happens every single time you open the app. Multiply by every user; that’s the load on the server.

If anything in that chain fails (token expired, server overloaded, network hiccup, database hung) you see one of the symptoms you’ve grown up with: “please try again,” “session expired,” “we couldn’t load your balance.” The HTTP status and any non-secret response text narrow the search, but they may be generic or missing. Capture them with the operation, time, scope, and retry result; engineers combine that evidence with logs and traces to identify the cause.

What you should carry into the next chapter

Client = asker. Server = answerer. One conversation, two roles. Always.
The server is a computer in a data centre, listening, serving thousands of clients at once. Your phone is a client; somebody’s laptop running npm run dev is briefly a server too.
HTTP is the language they speak. Method + URL + (sometimes) body in the request; status code + headers + body in the response.
Status codes come in five families. 1xx in progress, 2xx completed, 3xx redirect, 4xx request not fulfilled as sent, 5xx server could not complete an apparently valid request. The family starts the investigation; the exact code, response, operation, time, and scope make it useful.
JSON is the most common shape of response bodies. We’ll meet it properly in chapter 0A.5.
The next chapter (0A.4 — Databases) is the place inside the server where all the facts live — the world’s most important spreadsheet.

Previous: ← 0A.2 Frontend vs backend · Next: → 0A.4 Databases

Further reading

RFC 9110 — HTTP Semantics, status codes — the protocol definitions behind the five response families
MDN — Overview of HTTP — Mozilla’s authoritative plain-language reference
Julia Evans — How HTTP works — paid zine, the most readable thing on the topic
What is a Server? — Cloudflare’s primer — short, friendly, with diagrams