Skip to content

02 · THE HIDDEN ENGINE

Requests and responses

LOADING MODULE 02 · THE HIDDEN ENGINE · CHAPTER 01/06

Requests and responses

“When you press “Order”, what happens in between?”

  • About 15 min read
  • LAB 02 · The server’s coffee shop

You’ve pressed an “Order” button more times than you can count. In less than a second after your finger touches the screen, a small message sets off for another computer you have never seen. That computer wakes up, reads it, checks it, decides, and sends an answer back. In this chapter we’ll follow that journey one step at a time.

Part 1Every tap involves two computers

Think of a coffee-ordering app on your phone. When you order one latte, your phone does not make the coffee. It doesn’t know how many cartons of milk the shop has left, and it isn’t the one handing out queue numbers. All of that happens on another computer belonging to the shop, which might be hundreds of kilometers away.

Your phone has one job: to ask and then show the answer. The shop’s computer has the job of listening to the question, doing the work, and answering.

Stop and think

What would go wrong if every customer’s phone kept its own copy of the shop’s stock and could make decisions by itself?

These two roles have names you’ll hear throughout this book.

ClientThe one who asks
The program on the side that starts by asking, such as the browser on your computer or the app on your phone. It sends a request out and waits for an answer.
ServerThe one who serves
A program that waits for requests all the time. When a request comes in, it does whatever it was programmed to do and sends an answer back. The word is used both for the program and for the machine that runs it.

Part 2What one “request” looks like

That agreed format is called . Whichever company made the browser, and whatever language the server is written in, if they follow the same rules, they can talk.

Deep dive · for the extra curiousWhat does the browser do before the slip sets off?
Before sending its first request, the browser has to find out where coffee.example is. So it asks to turn the name into a number address, and then opens a connection to that machine. If the address starts with https://, the two sides first agree on encryption keys (these rules are called TLS), so the machines passing the data along can’t read the slip inside. The messages in this chapter are written in HTTP/1.1, the easiest version for people to read. Newer versions such as HTTP/2 and HTTP/3 pack the data in a more compact form, but the meaning stays the same. Finding addresses and encryption are opened up fully in Book 04.
RequestThe message that asks
The message a client sends to a server to say what it wants. It contains the action wanted, the destination address, information about the message, and content (if there is any).

This is what a real request to order one coffee looks like. All of this text is exactly what leaves your phone.

HTTP
POST /api/orders HTTP/1.1
Host: coffee.example
Content-Type: application/json

{
  "drink": "latte",
  "qty": 1,
  "customerName": "Mali"
}
A request for 1 latte
  • The first line says three things: POST is the , /api/orders is the “window” you want to reach on the server, and HTTP/1.1 is the version of the rules.
  • The next lines are called . For example, Host names the destination website and Content-Type says the content inside is written as JSON.
  • After the blank line comes the body, the content of the request. Here it is written in , saying which drink, how many cups, and what name.
ResponseThe message that answers
The message a server sends back to the client once it has finished its work. It reports whether it succeeded, along with any related data. Every request that reaches the server and gets answered receives exactly one response.
HTTP
HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/orders/ord_0042

{
  "id": "ord_0042",
  "drink": "latte",
  "qty": 1,
  "total": 65,
  "status": "brewing"
}
The response when the order succeeds

Look at the first line: 201 Created. This three-digit number is the most important part of the answer — browsers and programmers look at it before reading anything else. Notice one more thing: the 65-baht total and the order number come from the server. They weren’t worked out on the phone.

Part 3Three digits that tell you the result

HTTP Status CodeThe three-digit result code
The three-digit number on the first line of a response that sums up the result of the request as briefly as possible. The first digit tells you the “family” of the result; the last two give the details.

You don’t need to memorize every code. Just knowing what the first digit means lets you read almost every situation.

  • 2xx · Success You got what you asked for, for example 200 OK (here is the data you asked for) and 201 Created (something new was created).
  • 3xx · Go somewhere else What you asked for has moved to a new address, and the browser follows it for you. We’ll meet this family again in Book 04.
  • 4xx · Request problem The server is working fine but can’t do what this request asks. The sender has to fix the request, for example 400 Bad Request and 404 Not Found.
  • 5xx · Server problem The request may be perfectly correct, but the server itself went wrong, for example 500 Internal Server Error.

Stop and think

If a customer orders 0 cups of coffee, which code family should the server answer with?

A common belief

“Seeing a 404 page means the website is down”

Sort it · which code family should this get?

Correct 0/5

  1. 01A website’s home page opens normally

  2. 02You mistype a page’s address and end up asking for a page that doesn’t exist

  3. 03You haven’t logged in, but you try to open the account settings page

  4. 04The shop’s database is down, so the code on the server can’t carry on

  5. 05You send a message in an elevator just as the signal drops

Figure 1.1 · Sort everyday situations into code families, then read the reason for each one

Part 4Hands on: open your own coffee shop

Time to see the real thing. The lab below has three parts: on the left is the customer’s browser, in the middle is the network, and on the right is the server’s machine room, which the customer can’t see. Try these missions in order.

  1. Choose the All normal scenario and order. Watch the lights in the machine room come on one by one, and watch the stock go down.
  2. Switch to Sold out and order again. See which step the server stops at, and which code you get.
  3. Switch to Server crash. Notice that the request passes every check — so where does it break?
  4. Switch to Connection lost and look for the status code. You won’t find one. Think about why.
  5. Bonus mission: go back to All normal, then try deleting the name or lowering the quantity to 0.
Skip this lab and keep reading →
EXPERIMENT · Lab 02Every time you order, watch the data envelope travel and read the real request and response below the picture.
02

LAB 02 — Request Processing Engine

The server’s coffee shop

IDLESimulation
Everything in this lab happens only in your browser. No real data is sent out over the internet.

Scenario · choose one before you order

The server works as usual

coffee.example/order

Browser · customer side

Choose a drink
Quantity
1

Choose a drink, enter your name and order. This screen shows only what the server sends back.

Server · coffee.example

IDLE · waiting for requests

  1. Receive the requestWaiting
  2. Check the dataWaiting
  3. Check stockWaiting
  4. Save and brewWaiting
  5. Send the responseWaiting

Shop stock · the browser can’t see this

  • Latte6 cups
  • Americano8 cups
  • Cocoa4 cups
Request · draft to send (follows the form)
POST /api/orders HTTP/1.1
Host: coffee.example
Content-Type: application/json
Accept: application/json

{
  "drink": "latte",
  "qty": 1,
  "customerName": "Mali"
}
Response · waiting
// No response yet
// Press 'Order now' to send the request

What happened?

Press Order now and watch the blue envelope travel. That envelope is the request: the browser wraps up your order and sends it to the server. Then try changing the scenario above to see how each kind of failure is different — or set the quantity to 0, or delete the name.

4 kinds of outcome · Tried 0/4

  • 2xx

    Success

    You got what you asked for, e.g. 201 Created

  • 4xx

    Request problem

    The sender must fix the request, e.g. 400, 409

  • 5xx

    Server problem

    Not the customer’s fault, e.g. 500

  • No code

    Never arrived / no answer

    A problem on the way. No response

Part 5They all failed, but in completely different ways

If you finished every mission, you’ve just seen four kinds of failure that most users lump together as “the website is broken.” For people who build websites, though, the four are very different, because a different person has to fix each one.

  • 400 Bad Request The data sent was in the wrong shape, such as no name or a quantity of zero. The sender has to fix it.
  • 409 Conflict The data is correct but clashes with the current state: the item is sold out. In the lab we use 409; some systems use 422 instead. Both are in the 4xx family, and the server didn’t break — it simply answered clearly that it can’t do it.
  • 500 Internal Server Error Nothing is wrong with the request, but the shop’s own code hit an error partway through. The shop’s team has to fix it; the customer can only wait and try again.
  • Connection lost There is no code at all, because no answer came back to read.

One more thing worth knowing: sometimes you may see a 502 or 504 code when a site is very slow. These codes usually come from a “machine along the way” that receives requests on behalf of the main server. When that machine can’t reach the main server, it writes a response to tell us itself. So there still is an answer — unlike a lost connection, where nobody answers at all.

A common belief

“If the app says “Can’t connect,” the shop didn’t get the order, so it’s fine to order again right away”

Practice looking at it the way a web builder does. Don’t just ask “did it succeed or fail?” — go on to ask who has to do what next. Read each situation at the coffee shop, then choose who has to act.

Sort it

Who has to act next?

Correct 0/4

  1. 01The app sends an order with no customer name and gets 400 Bad Request

  2. 02You order 3 cocoas, but the shop has only 2 left, and you get 409 Conflict

  3. 03The shop’s pricing code has a bug, and every order gets 500 Internal Server Error

  4. 04You order, the signal drops on the way, and no code comes back at all

Goal: Get every answer right, then read the reason for each one

Figure 1.2 · Each kind of failure points to a different person to fix it

Stop and think

The coffee shop’s web page already checks that a name is filled in before you can order. So why does the server have to check again?

Part 6The whole picture of one tap

Now you’ve seen that one press of a button has five beats: the browser writes a request following the HTTP rules, the request travels across the network, the server works — checking, deciding and saving — the server writes a response with a status code, and the browser shows the result to you.

Let’s follow Mali’s latte order once more, slowly this time, one step at a time. Notice which machine each step happens on, and where the answer could have come out as 400 or 409 instead of 201.

Follow it step by step

The journey of order ord_0042

Step 1/8
  1. Phone
  2. Network
  3. Server

PhoneWrite the request

Mali orders 1 latte. The app writes a request following the HTTP rules: method POST to the window /api/orders, with a JSON body giving the drink, the quantity and the name.

Goal: Press “Next step →” until the last step

Figure 1.3 · One latte order, from a finger on the screen to the word “Brewing”

In the lab, the server “remembers” the stock by itself. But in a real system, if the server shuts down or restarts, that memory is gone instantly. So real servers keep important data somewhere else that is designed specifically for remembering. That place is the database, the heart of Book 03.

SYSTEM SUMMARY

Chapter summary

  • 01The client is the side that asks; the server is the side that listens, works and answers. The code that runs on the server is called the backend.
  • 02Requests and responses are messages written according to the HTTP rules, with a first line, headers and a body.
  • 03The first digit of an HTTP status code gives the family: 2xx success, 4xx request problem, 5xx server problem.
  • 04A lost connection has no status code, because there is no response, and the browser doesn’t know whether the request arrived.
  • 05Important data such as prices and stock must be decided on the server, not on the customer’s device.
Skip the quiz and keep reading →

End of chapter

Check your understanding

Answered 0/4

Nothing is graded and nobody sees your answers but you. Every choice comes with an explanation — right ones and wrong ones.

Question 1

Question 1

When you order a coffee in the app, who decides whether the shop still has enough?

Question 2

Question 2

You get a response starting with 409 Conflict after ordering 3 cocoas. Which explanation fits best?

Question 3

Question 3

Why does the “Connection lost” scenario have no HTTP status code?

Question 4

Question 4

The web page already checks that the quantity isn’t zero. Does the server still need to check again?

One last step: try explaining it in your own words. This isn’t a test — the system doesn’t read or grade your answer. But putting it into your own words is the best way to find out whether you really understand.

Explain it in your own words

What you write stays on your screen. It is not sent or saved anywhere, and nothing is graded.

Write a little more (0/30 characters)

Learning path

0/4

  1. Work out who has to fix each kind of failure (not done yet)Figure 1.2: get every answer right
  2. Follow one latte order through every step (not done yet)Figure 1.3: press “Next step →” until the last step
  3. Answer every question in the end-of-chapter quiz (not done yet)Answer them all. Wrong answers are fine — they don’t affect the check mark
  4. Explain it in your own words (not done yet)Write at least 30 characters, then press “Compare with a sample explanation”

This list records what you actually did in this browser — it is not a certificate that you understand. The best test is to explain it to someone else. You can clear the record in the Machine Lens, DATABASE tab.

NEXT DISCOVERY · End of Chapter 1

Chapter 2: The server’s many doors

URLs, routes and HTTP methods like GET, POST, PUT and DELETE that tell the server what we want to do.

Checking access