How API Requests Work, From Tap to Data

by Souy Soeng /October 03, 2026

Diagram of an API request as a relay race through DNS, TLS, request headers, server, status code and caching

To understand how API requests work, picture a relay race. A request is passed from step to step: a DNS lookup, a secure connection, the request itself, the server's internal work, and a response that comes back with a status code. You tap refresh, and all of that happens in roughly a blink.

This guide walks through each leg of that race in plain language. You'll learn what each step does and why it exists. You'll also learn what it looks like when that step breaks, so the next time a spinner spins forever, you'll know where to look instead of restarting things and hoping.

The quick version

An API call is a chain of small steps, and it usually breaks at just one link.
DNS finds the server, then TCP and TLS open a reliable, private connection.
A request has a method, a path, headers and sometimes a body.
The status code's first digit tells you who's probably responsible: 2xx good, 4xx you, 5xx them.
Caching skips most of the race, trading some freshness for speed.

Why an API call is really a relay race

You open an app, pull to refresh, and the spinner just keeps spinning. Is it your Wi-Fi, the app, or a server somewhere having a very bad day? If you see the call as one big mysterious thing, you can only guess. Most beginners debug by vibes. They restart, reinstall, or message the backend team in all caps.

An API call is actually a chain of short legs, and each runner has exactly one job before handing off the baton. DNS finds where the server lives. A secure connection opens. The request goes out, the server does its work, and a response races back. None of these steps is complicated on its own. Chaining them together very quickly is what makes it feel like magic.

The catch is that if any runner drops the baton, the whole race fails. Your screen won't tell you which runner it was. It just spins. That's why knowing the legs matters, and it matters for testers, designers and curious users as well as developers. A DNS error, a 401 and a 500 can show you the same spinner, but each one needs a completely different fix.

Leg 1: DNS finds the server's address
Leg 2: TCP and TLS open a secure line
Leg 3: The request is sent
Leg 4: The server does the work
Leg 5: The response comes back

How does DNS turn a domain name into an IP address?

Your app knows the server by name, something like api.weather.com. Computers don't route traffic by names, though. They route by numbers called IP addresses. DNS translates one into the other, the same way your phone's contacts let you tap 'Mom' instead of typing her number.

Your device doesn't do the lookup itself. It asks a resolver, usually run by your internet provider or a public DNS service. The resolver works through a hierarchy, like asking a friend who knows a friend. It asks the root servers who handles .com. Then it asks .com who handles weather.com. Finally, weather.com's own name servers return an address such as 203.0.113.10. Answers are cached for a while, so most lookups are nearly instant after the first one.

When DNS fails, you'll see errors like 'could not resolve host'. That means the race died on leg one. The server may be perfectly healthy, and you simply never found its door. Honestly, it's often a typo or a missing config value, so check the spelling before you try anything fancier.

Check the device cache → not found
Ask the resolver → it asks the root servers
The root points to the .com servers
.com points to weather.com's name servers
Answer: 203.0.113.10

TCP handshake and TLS: opening a secure connection

Once you have an address, you need a reliable line to the server. That's TCP's job, and it begins with a polite three-step handshake. Your device sends a SYN ('can you hear me?'). The server answers with a SYN-ACK ('yes, can you hear me?'). Your device replies with an ACK ('loud and clear'). It's like two people on a bad phone line checking the call works before they say anything important.

Why go through the ceremony? TCP promises that data arrives complete and in order, and it resends anything that gets lost. The cost is one round trip before any real work starts. That's why apps try to keep connections open and reuse them. A slow first request is often just the handshake.

A plain TCP line is like talking across a crowded café, where anyone nearby can listen. HTTPS adds TLS on top, which works like a secret knock. The server shows a certificate, which is an ID card signed by someone your device already trusts. Then both sides agree on secret keys. After that, anyone snooping sees gibberish instead of your login token. If the certificate is expired or doesn't match, your app refuses to continue. That's annoying, but it's deliberate protection.

What does an HTTP request look like?

Here's the pleasant surprise: an HTTP request is mostly structured text. The first line holds the method and the path, with any query, such as the city, tucked onto the end. The headers follow, one per line. A GET request like this one has no body, because it's only asking for something.

Think of the method as the verb and the path as the noun. GET reads data. POST creates or sends data. PUT and DELETE update or remove things. The path says exactly what you mean, like /forecast or /users/42. Once you recognise this shape, you'll spot it everywhere: in browser dev tools, in logs and in API docs.

GET /v1/forecast?city=Paris HTTP/1.1
Host: api.weather.com
Authorization: Bearer abc123
Accept: application/json
# no body: a GET just asks

GET vs POST, headers and the request body

The difference between GET and POST looks small on paper and turns out to be big in practice. Repeating a GET is harmless because it only reads. Repeating a POST might create two comments, or two orders. That's why checkout pages beg you not to press the button twice. Pick the method that matches the action you actually want.

Headers are key-value notes attached to the request, a bit like a cover letter the server always reads. Authorization carries your token or API key, which works like a wristband at a venue. If it's missing or expired, you'll usually get a 401. Content-Type says what format your body is in. Accept says which format you'd like back.

When you send data, it travels in the body. If the headers are the label on a parcel, the body is what's inside the box, and a blank line separates the two. Most modern APIs use JSON, which is just curly braces with names and values. The label has to match the contents. A lot of 'the server ignores my data' bugs turn out to be mislabelled packages.

GET: reads data, usually has no body, safe to retry
POST: creates data, usually has a body, may duplicate if repeated
PUT / DELETE: update or remove, generally safe to retry

POST /v1/comments HTTP/1.1
Content-Type: application/json
Authorization: Bearer abc123
# blank line, then the body
{"post": 42, "text": "Nice!"}

What happens inside the server?

Your request usually doesn't land on a single machine. Big apps run many copies of their code, and a load balancer at the front decides which copy handles each request. It's like a supermarket worker waving you toward the shortest checkout line. It spreads the load and skips servers that are unhealthy. It also means two identical requests can land on different machines, which helps explain bugs that seem random.

After the load balancer there are often more checkpoints, a bit like check-in, security and the gate at an airport. An API gateway checks your token, enforces rate limits and routes the request. The application code then validates your input and applies the business rules. Finally, the database fetches or saves the actual data. Rejecting a bad request early is much cheaper than failing at the very end.

Every layer the request goes down, the answer has to climb back up. The database is often the slowest runner, because of big tables, complex queries and busy moments. So servers keep popular answers in a fast cache. If thousands of people ask for the weather in Paris, the server can fetch it once and serve it many times.

What do HTTP status codes mean?

Before any data arrives, the server sends back a three-digit status code. It's the verdict, and it's the most useful clue you'll get when debugging. 200 means everything worked and your data is in the body. 404 means the server is fine but the thing you asked for isn't there, often because of a typo in the path, an old link or a deleted item. 500 means something broke on the server's side, even if your request was perfect.

You don't need to memorise every code. The first digit tells you the family, and the family tells you who's probably responsible. Retrying a 4xx without changing anything is pointless. A 5xx might clear up if you wait. 3xx codes are redirects ('this moved, look over there'), and most tools follow them for you automatically.

2xx (200 OK, 201 Created): it worked
4xx (401, 403, 404): your request was off, so you fix it
5xx (500, 502, 503): the server broke, so it's their fix

Reading the JSON response and how caching helps

A response has the same shape as a request, travelling the other way. It starts with a status line, then the headers, then the body. In the example, the headers include Content-Type for JSON and Cache-Control, and the body says the city is Paris and the temperature is 18. Your app reads that and draws a little sun icon.

There's a sneaky failure to watch for. The status is 200, yet the app still breaks, because the JSON changed shape. The app expected a field called temp and got temperature instead. Response headers are worth reading too. They carry hints about format, caching rules and sometimes how many requests you have left.

Caching is the cheat code. If the answer probably hasn't changed, a saved copy can be reused from memory or disk, and the server never hears about it. Caches live in your app, your browser, a content delivery network near you, and on the server. The catch is staleness. Cache too long and users see yesterday's weather, which is why headers decide how long an answer can be trusted.

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=300
{"city": "Paris", "temp": 18}
# your app turns this into the screen

Common API mistakes and how to debug them

Put it all together with one weather refresh. DNS returns 203.0.113.10. TCP and TLS open a secure line. The app sends GET /forecast with its token. The server misses its cache, asks the database, and replies with a 200 and some JSON. Refresh a few seconds later and most legs are skipped, because DNS is cached, the connection is reused and the server now has Paris cached. Each failure maps to a leg: being offline breaks DNS, an expired token gives a 401, and a database that's down gives a 500.

The same few mistakes trip up nearly everyone, including experienced developers. The biggest is code that only handles success, so the app crashes or shows nothing when a 404 or 500 arrives. Next come header problems, such as a missing or expired token, or a body labelled with the wrong Content-Type. The last is blaming the wrong leg. Shouting at the backend team over a 400 caused by your own typo is not a great look.

Check the status code first and handle 4xx and 5xx on purpose
Compare your headers with the API docs line by line
Read the error, find the leg, then fix it

What to remember

Every API call runs the same relay: find the server, connect safely, ask clearly, let the server work, read the verdict.
'Could not resolve host' is a DNS problem, so check the domain spelling first.
Method and path form the question, headers are the fine print, and the body is the package.
First digit, first clue: 2xx good, 4xx you, 5xx them.
A 200 can still break your app if the JSON changes shape.
Caching speeds things up, but cached data can go stale.

Questions people ask

Why is the first API request slower than the ones after it?

The first request has to do a DNS lookup, a TCP handshake and a TLS setup before any data moves. Later requests can reuse cached DNS answers and open connections, and they may even get a cached response, so many of those steps are skipped.

What's the difference between a 401 and a 500 error?

A 401 is in the 4xx family, which means something about your request was off. Usually the token is missing or expired. A 500 means something broke inside the server, so your request might be perfectly fine and the fix is on their side.

Why does the server ignore the data I send in a POST request?

A common cause is a mismatch between the body and the Content-Type header. If you send JSON, the header needs to say JSON, or the server may read your data as nonsense.

Is it safe to retry a failed API request?

Retrying a GET is generally harmless because it only reads data. Retrying a POST can create duplicates, such as a second comment or order. A 4xx error won't fix itself if you resend the same request, while a 5xx might clear up after a short wait.

What does 'could not resolve host' mean?

It means DNS couldn't turn the domain name into an IP address, so the request never reached the server. Check for a typo in the domain or a missing config value, and make sure you're actually online.

Watch the full video on YouTube →

Tag

Ad