software-engineer-blog logoSoftware Engineer Blog

Module 5 · Networking

Unit 18 of 49

Unit 18 · Module 5 · Networking

HTTP/1.1 vs 2 vs 3, status codes, and how to design REST paths

One protocol family, three answers to "why is it slow", a status line that says whose fault it is, and one naming convention worth arguing about.

Unit 18 of the free 49-unit computer-science course, in networking. 4 topics to watch or read, 3 interview questions answered in full and a short self-check.

Watch or read

4 topics make up this unit. Take each one whichever way suits you, then answer the questions below.

gRPC vs REST

REST and gRPC are two ways to build an API. REST is ordering à la carte off a web menu — a plain HTTP request to a resource, JSON back, anyone can call it. gRPC is a dedicated phone line with a strict contract — a Protobuf schema, generated typed stubs, compact binary over HTTP/2 with streaming. Here's how they actually differ on speed, payload, reach, and tooling — with code — and a clear rule for which to reach for.

ReelRead

API gateway

An API gateway puts a single front door in front of all your services — one entrance every request has to pass through, including the bad ones. Here's the problem it solves, how it terminates TLS, authenticates, rate-limits, routes, and aggregates in one place, and why the same idea now guards your LLM calls too.

ReelRead

SSE vs WebSockets vs polling

Read

WMS vs WMTS vs WFS

Read

Interview questions this unit unlocks

Asked out loud, answered out loud. Read the answer, then say it in your own words.

What problem does HTTP/2 solve that HTTP/1.1 has?

Head-of-line blocking at the application layer. In 1.1 a connection carries one request at a time, so browsers opened six connections per host and pipelined badly around it. HTTP/2 multiplexes many streams over one connection, compresses headers, and lets the server prioritise. It does not fix head-of-line blocking in TCP itself — one lost packet still stalls every stream on that connection, which is precisely what HTTP/3 moves to QUIC over UDP to escape.

How do you decide between 400, 401, 403, 404 and 422?

400 the request is malformed and I could not parse it. 401 I do not know who you are — authenticate and try again. 403 I know exactly who you are and you may not do this; retrying with the same credentials will never work. 404 there is nothing at this address, or I am unwilling to admit there is. 422 I parsed it fine and the values are invalid. The pair people get wrong is 401 versus 403: one is about identity, the other about permission.

A deliberate 404 in place of 403 is a real pattern — it stops an attacker learning which resource ids exist.

How would you design the URLs for a REST API?

Nouns for resources, plural, with the hierarchy in the path and everything else in the query string: `/users/42/orders?status=open&page=2`. The verb lives in the HTTP method, never in the path, so `/getUser` is a red flag. Keep the response shape stable, version at the edge when you must break it, and make collection endpoints paginated from day one rather than the day the collection gets large.

The follow-up worth pre-empting: PUT replaces the whole resource and is idempotent; PATCH applies a partial change and usually is not.

Self-check — 6 questions

Answer alone, at 2am, with no interviewer in the room.

Part of Everything You Need to Know About Computer Science.