A 38-minute working session on the verbs of the web — GET, POST, PUT, PATCH, DELETE — the safety and idempotency rules behind them, the status codes that matter, how to model a resource so clients, caches and proxies all agree on what your endpoint does, and the tools and API styles you'll reach for in practice.
HTTP isn't just a pipe for moving bytes — it's a shared contract. Between your code and the server sits a crowd of helpers: the browser, a CDN (a network of edge servers that keep copies close to users), proxies and load balancers (relays that forward and spread out traffic), and your own retry logic. Each of them reads the method and decides, on its own, what it may do: store the answer, fetch it ahead of time (a prefetch), or send it again after a timeout. Break the promise the method makes and that whole crowd quietly works against you.
GET /users/42 HTTP/1.1).Method + path + headers + body in; status + headers + body back. The verb at the top governs everything.
Rule zero: the method must tell the truth about the effect. Everything in this talk follows from that one promise.
GET, POST, PUT, PATCH and DELETE cover almost everything you'll build; HEAD and OPTIONS exist for metadata and negotiation. Click through each — note what it does to state and whether it carries a body.
/users/42 means "read", "replace" or "remove" depending entirely on whether the verb is GET, PUT or DELETE. The noun is the URL; the verb is the method./orders) decides the new id, not the client.Networks drop responses all the time. Whether your client, a proxy, or a load balancer can safely repeat a request comes down to two words — and getting them wrong is how you end up charging a card twice.
Pure reads. Cache them, prefetch them, retry them — nothing downstream changes. Cacheable by default.
They mutate, but the end state is stable: PUT this exact body twice → same record; DELETE twice → still gone. Retries are safe.
POST twice makes two resources. A delta-PATCH (balance += 10) compounds. Repeat only with an idempotency guard. *set-PATCH is idempotent
The response is lost, not the request. The retry is identical — so idempotency is the only thing standing between you and a duplicate.
When you genuinely need a non-idempotent create to survive retries, let the client send an idempotency key. The server records it and returns the original result on a repeat — no duplicate.
Like a coat-check ticket — hand over the same stub twice, you still get back the one coat.
A status code is a three-digit summary the whole stack understands. You don't need all 60-odd — you need to use the right class, and the dozen codes you'll actually return.
Location header.Retry-After.The split that matters most for automation: 4xx = don't retry, fix the request; 5xx = the server failed, retrying an idempotent verb is fine.
REST's core trick: don't put the action in the URL. Name a resource, then let the HTTP method say what to do with it. One consistent shape replaces a sprawl of custom endpoints.
A collection holds items; items can hold sub-collections. The same six methods apply at every level.
/users, /orders — not /getUser./users/42/orders reads as "user 42's orders".?role=admin&sort=name&page=2 — not new paths./purchase-orders, never /PurchaseOrders/create.Like a filing cabinet: drawers and folders are nouns; what you do (file, read, shred) is the action you bring.
The body is the payload; the headers are the contract around it — what format, what auth, how long it stays fresh. Two patterns earn their keep daily: content negotiation and caching.
The client states what it accepts; the server declares what it sent. Same URL can serve JSON, CSV, or a different language depending on the ask.
Cache-Control sets the freshness budget; an ETag is a fingerprint of the body. Together they let a client skip the download when nothing changed.
The client sends its ETag back; if it still matches, the server answers 304 with no body — a near-free response.
If-Match) also prevent lost updates — reject a PUT whose ETag is stale with a 409 Conflict.Semantics unlock the network. Honest verbs let caches, CDNs and conditional requests do real work for free — break them and you opt out of all of it.
Everything so far is protocol. Day to day you'll poke an API with a client, describe it with a spec, and pick an overall style. Here are the leading options, with one honest upside and one honest downside each — and a plain rule for choosing.
A tiny terminal program, already on almost every machine, that speaks raw HTTP. You type the method, URL, headers and body yourself.
The most popular point-and-click API client. You build, save and share requests, group them into collections, and add tests and mock servers.
An open-source graphical client, leaner than Postman, with first-class support for both REST and GraphQL and easy OpenAPI import.
How to choose: reach for curl to automate and debug, Postman when a team needs to share a big documented API, and Insomnia when you want a fast local client or live in GraphQL.
Nouns in the path, HTTP methods as the verbs — exactly what this whole talk has been about. The default for most web APIs.
A single URL where the client sends a query naming exactly the fields it wants, and gets back just those — no more, no less.
A binary, contract-first style (over HTTP/2) where you call typed service methods — UserService.Get() — almost like calling a local function.
How to choose: REST for public, resource-shaped APIs; GraphQL when clients need flexible, deeply nested data; gRPC for fast internal service-to-service traffic.
Same data, three shapes: REST makes several calls, GraphQL asks for it all in one query, gRPC makes a single typed call.
Like ordering lunch: REST is three separate counters, GraphQL is one custom order, gRPC is a standing arrangement with the kitchen.
Everything so far lands in a single design choice. Take "cancel an order" and watch the rules apply at once.
"The URL is the noun, the method is the verb — make them both tell the truth."
— the whole talk, in one line
Five quick questions on HTTP methods, safety & idempotency, status codes and REST — instant feedback, no sign-in.
Navigate with ← → or scroll · back to library