3. Client and Server
1
The picture to keep in your head2
3.1 What exactly are a client and a server?3
3.2 What's a request and a response?4
3.3 What happens when you type a URL and press Enter?5
3.4 What do GET, POST, PUT, PATCH and DELETE mean?6
3.5 What do status codes tell you?7
3.6 What goes in the headers and what goes in the body?8
3.7 What's the difference between TCP and UDP?9
3.8 How does HTTPS keep the conversation private?10
3.9 Why do keep-alive, HTTP/2 and HTTP/3 make things faster?11
3.10 What does "stateless" mean, and why do we want it?12
3.11 How do cookies, sessions and tokens remember who you are?13
Memory card and where the analogy breaks14
Practice: five levels15
Interview questions16
Solutions17
Sources18
Code lab3. Client and Server
3.4 What do GET, POST, PUT, PATCH and DELETE mean?
3 min read+10 XP
Speaking HTTP
In the restaurant: There are only a few kinds of thing you say to a waiter: "show me the menu", "I'd like a dosa", "change my whole order to this", "just make the coffee cold", "cancel the dessert".
In the system: The method says what kind of action you want.
| Method | Meaning | Bookstore example |
|---|---|---|
| GET | Read something | GET /books/42 |
| POST | Create something, or trigger an action | POST /cart with {"book_id": "42"} |
| PUT | Replace something completely | PUT /users/7/address with the full new address |
| PATCH | Change part of something | PATCH /users/7 with {"phone": "..."} |
| DELETE | Remove something | DELETE /cart/items/3 |
Two properties interviewers love:
- Safe: the method doesn't change anything on the server. GET (and HEAD, OPTIONS) are safe. Asking to see the menu doesn't cook anything.
- Idempotent: doing it twice has the same effect as doing it once. GET, PUT and DELETE are idempotent: replacing your address with the same address twice leaves one address; deleting an item twice leaves it deleted. POST is not: sending "add book 42 to cart" twice can add it twice. PATCH isn't guaranteed to be idempotent either.
Why it matters: networks fail. When a request times out, the client often doesn't know whether it worked. Retrying an idempotent request is safe. Retrying a POST can double-order or double-charge, which is why payments need idempotency keys (Chapter 24).
Memory code: "GET looks, POST adds, PUT replaces, PATCH tweaks, DELETE removes." Safe = changes nothing. Idempotent = twice is the same as once.