Explained Simply · APIs
How a request travels
Last time, we met the client and the server. Now let’s follow one request on its trip, from the moment your app asks a question to the moment the answer appears on your screen.
Our running example is the travel app. A user taps “Check the weather in Paris for Friday.” Behind that one tap, a request starts a journey.
Everyday comparison: Think of mailing a parcel. You write the address and the contents. The postal network finds the route. The sorting office checks the parcel is allowed through. The receiving warehouse prepares the item, and a reply travels back the same way. If something goes wrong, the tracking history shows where it stopped.
Step 1: Your app builds the request
The app writes down exactly what it wants. That includes:
- The method, which describes the action. “Get” means fetch something, and “post” means send something new.
- The address, a URL that names the resource, such as a forecast for Paris.
- Headers, short labels with extra information, such as the format the app can read.
- Data, if the request needs to send anything.
Everything needed to ask the question goes into this one package. The server never sees the app’s screen, so the request has to explain itself completely.
Step 2: DNS finds the server
Computers talk to each other using numeric addresses, not names. The Domain Name System works like a phone book. It takes a name like api.example.com and returns the address of a machine that can answer. Devices usually remember recent lookups, so this step is often fast after the first time.
Step 3: The API checks the request
Before any real work starts, the API checks the parcel. It asks questions like these:
- Is the API key valid?
- Is the request in the format the API expects?
- Has this client sent too many requests in a short time?
If a check fails, the API sends back an error straight away and does no further work. This protects the rest of the system from bad or unwanted requests. It’s also why a missing key fails quickly rather than slowly.
Step 4: The server does the work
Now the real work happens. The server might look up forecast data in a database, call another service, run a calculation, or do all three. This is usually the slowest stop, because the answer depends on the most work. When an API feels slow, look here first.
Step 5: The response comes back
Get ThinkTaught’s stories in your inbox
Join Medium for free to get updates from this writer.
The server sends its answer. A response has two main parts:
- A status code, a three-digit number that summarises the outcome. 200 means success, 401 means the key was rejected, 404 means the thing wasn’t found, and 500 means the server failed.
- A body, usually JSON, which holds the answer itself, such as the temperature and the forecast for Friday.
The status code comes first on purpose. Your app can check it before reading the body, so it knows right away whether the answer is worth using.
Step 6: Your app shows the result
The app reads the JSON, picks out the fields it needs, and updates the screen. From the user’s point of view, the forecast simply appears. The whole trip often takes less than a second, even though it crossed several machines and networks.
Where the journey breaks, and what to check
When something goes wrong, the route tells you where to look:
- A wrong or missing key fails at step 3, so check your credentials.
- A typo in the address fails at step 2 or step 3, so check the URL.
- A slow answer usually points to step 4, so look at the server’s work.
- A 500 error appears at step 5, but the request itself may be fine, so retry later.
This is one of the most useful habits in API work: follow the request, not the symptom.
Quick recap
- A request is a package: method, address, headers and data.
- DNS turns a name into a server address.
- The API checks the request before doing any work.
- The server does the work and sends back a status code and a body.
- Your app reads the answer and updates the screen.
- Each stop can fail, and knowing the route tells you which one.
One question to take with you
We now know the route a request takes. But both ends have to agree on the shape of the package and the answer, including the labels on the envelope and the format of the message inside. So what language do they speak?
That’s what the next episode answers: What is HTTP?
Follow ThinkTaught so you don’t miss it. If something here is unclear, tell me in the comments. We’re learning this together.
