Today I want to go one level deeper. Not what the stages are, but what they reveal about frameworks themselves.

Two kinds of code

Look at those four stages again. Three of them — route matching, request parsing, response serialization — are HTTP plumbing. They exist because HTTP speaks text, and your code speaks objects. Someone has to translate.

The fourth — business logic — is yours. It’s the reason the server exists. Find user 42. Check if the email is taken. Calculate the total.

No framework can write that part for you, because it changes with every application. But the plumbing? That’s the same every time. Parse JSON, match a URL, serialize a response. Repetitive work that never changes regardless of what you’re building.

That’s what a framework is. It automates the repetitive HTTP plumbing so you can focus on the part that actually matters — your business logic.

The automation spectrum

But frameworks don’t all automate the same amount. Here’s what I found when I mapped out who does what:

Go (net/http) — route matching only. You parse the request body yourself with json.Decoder. You serialize the response yourself with json.Encoder. You check HTTP methods with an if-statement.

Express — route matching and response serialization. app.get() handles both method and path. res.json() serializes for you. But request parsing? You need to register express.json() middleware yourself. It’s not on by default.

Spring — everything. @GetMapping scans and registers routes at startup. @RequestBody deserializes JSON into a typed object. Returning an object from a handler automatically serializes it. You write a method, add some annotations, and the framework handles the rest.

Three tools, same four stages, different levels of automation.

Opinionated vs unopinionated

This difference has a name.

Spring is opinionated. It assumes you’ll use JSON. It assumes you want automatic type conversion. It assumes convention over configuration. The framework makes decisions for you.

Express is unopinionated. It doesn’t assume you want JSON parsing — maybe you’re handling XML, or form data, or raw binary. It gives you the pieces and lets you assemble them.

Go’s standard library isn’t even a framework. It gives you the bare minimum: a way to listen for requests and send responses. Everything else is your problem.

The trade-off

More automation means more convenience. Spring lets you write a three-line handler and get a fully working endpoint. You ship faster. You write less boilerplate.

But more automation also means less flexibility. When Spring auto-serializes your response, you don’t control the JSON field order, or how nulls are handled, or whether empty arrays become [] or get omitted. You can configure these things, but now you’re fighting the defaults instead of just writing code.

Express sits in the middle. It helps where you ask it to, stays out of the way otherwise. You get convenience where you want it and control where you need it.

Go gives you nothing you didn’t ask for. Verbose, but transparent. When something breaks, there’s no magic to debug — just your code.

What I actually learned

The insight isn’t that Spring is better or Go is purer. It’s that the pipeline is constant:

Route matching → Request parsing → Business logic → Response serialization.

Every HTTP framework is just a different answer to one question: how much of that pipeline should be automated?

When I pick up a new framework now, I don’t memorize syntax. I ask: where on the spectrum does this sit? What does it automate, and what does it leave to me? The answer tells me almost everything I need to know about how it will feel to work with.

They all do the same thing. The difference is just how much they do for you.

The experiment

Here’s the same endpoint in three frameworks.

Go:

http.HandleFunc("/users/", func(w http.ResponseWriter, r *http.Request) {
    if r.Method != "GET" {
        w.WriteHeader(405)
        return
    }
    id := r.URL.Path[len("/users/"):]
    json.NewEncoder(w).Encode(map[string]string{"id": id})
})

Express:

app.get('/users/:id', (req, res) => {
    const user = findUser(Number(req.params.id));
    if (!user) return res.status(404).json({ error: 'Not found' });
    res.json(user);
});

Spring:

@GetMapping("/users/{id}")
public User getUser(@PathVariable Long id) {
    return userRepository.findById(id)
        .orElseThrow(() -> new ResponseStatusException(HttpStatus.NOT_FOUND));
}

At first they look completely different. Annotations, callbacks, raw if-statements. But when I traced what actually happens at runtime, a common structure showed up.

The four-stage pipeline

Every HTTP framework processes a request through the same four stages:

1. Route matching — find which handler should process this request.
2. Request parsing — extract parameters, convert types.
3. Business logic — do the actual work.
4. Response serialization — turn the result into JSON and send it.

That’s it. No framework skips any of these steps. The only question is: who does each step?

Who does what

Route matching

Go only matches the path. It doesn’t care about HTTP methods at all — you check r.Method yourself with an if-statement. Express matches both method and path through app.get(). Spring scans your classes at startup, finds @GetMapping annotations, and registers routes automatically.

Same problem, three levels of automation.

Request parsing

In Go, the path parameter doesn’t even exist as a concept. You slice the URL string yourself: r.URL.Path[len("/users/"):]. Express gives you req.params.id, but it’s always a string — you call Number() yourself. Spring sees @PathVariable Long id and converts "42" to Long 42 automatically.

Again, same problem. Go makes you do everything, Express does half, Spring does all of it.

Response serialization

Go: you create a JSON encoder and write to the response writer manually. Express: you call res.json(). Spring: you just return an object and the framework serializes it.

Business logic

This is the one row where all three frameworks are identical: you write it yourself. No framework can know that you want to find user 42 in a database. Routing, parsing, serialization — that’s all plumbing. Frameworks can automate plumbing. They can’t automate your business logic.

The pattern behind the pattern

The columns go from left to right: raw → convenient → automated. This maps directly to a concept called Inversion of Control. In Go, you control everything. In Express, you control most things but the framework handles routing and provides helpers. In Spring, the framework controls the flow — it finds your code, calls it, converts types, and serializes responses. You just declare what you want with annotations.

The trade-off is clear. More automation means less boilerplate but more magic. Go gives you nothing you didn’t ask for. Spring gives you everything, whether you understand it or not.

What I took away

When I see a new framework now, I don’t try to memorize its API. I ask four questions:

1. How does it register routes?
2. How does it parse requests?
3. Where do I put my logic?
4. How does it build responses?

Every HTTP framework is just a different answer to these four questions. The pipeline is always the same.

When you build an API, the URL should point to a thing, not an action. That thing is called a resource.

• /users → the user collection
• /users/3 → the specific user with ID 3

You might be tempted to name your endpoints /getUsers or /createUser. I did that too. But the problem is that you’re baking the action into the URL. REST says: let the URL just describe what you’re talking about. The how part? That’s someone else’s job.

URI Design Rules

A few conventions that keep URIs sane:

• Use nouns: /users, /posts, /comments
• Plural for collections: /users not /user
• Nest for relationships: /users/3/posts — posts that belong to user 3
• No verbs: /users, never /getUsers

Think of a URI as a street address. It tells you where something is, not what to do with it.

HTTP Method Meaning

So if the URL doesn’t say what to do, what does? The HTTP method.

• GET — read
• POST — create
• PUT — update
• DELETE — remove

They all work on the same URL:

GET    /users     → list all users
POST   /users     → create a user
PUT    /users/3   → update user 3
DELETE /users/3   → delete user 3

Here’s something worth knowing: idempotency. If you accidentally send the same request twice, what happens?

• PUT /users/3 with { name: "Alice" } twice → still Alice. Same result. That’s idempotent.
• POST /users with { name: "Alice" } twice → now you have two Alices. Not idempotent.

GET, PUT, and DELETE are idempotent. POST is not. This actually matters — when the network is flaky and a request fires twice, idempotent methods are safe to retry. POST needs extra care.

Status Code Classification

When the server responds, it sends back a number. You’ve seen 404 on broken web pages. That number is the status code, and it follows a simple pattern by the hundreds digit:

• 1xx — Informational
• 2xx — Success
• 3xx — Redirect
• 4xx — Client messed up
• 5xx — Server messed up

You don’t need to memorize all of them. Just a handful comes up over and over:

• 200 — all good
• 201 — all good, and something new was created (typically after POST)
• 204 — all good, but there’s nothing to send back (typically after DELETE)
• 400 — bad request, something’s wrong with what you sent
• 404 — that resource doesn’t exist
• 500 — something broke on the server side

The point is: the client can understand the result from the number alone, before even reading the body.

HATEOAS

This one sounds fancy. HATEOAS — Hypermedia As The Engine Of Application State.

The idea is simple: what if API responses included links, like a website does? You land on a page, you see links, you click one and go somewhere new. What if APIs worked the same way?

{
  "id": 3,
  "name": "Alice",
  "links": {
    "posts": "/users/3/posts",
    "delete": "/users/3"
  }
}

The client wouldn’t need to know URLs in advance. Just follow the links.

Sounds great, right? In practice, almost nobody does this. Frontend developers already know exactly which endpoints to hit — they hardcode those calls for each screen. Parsing links from every response just to figure out where to go next adds complexity for no real gain. Elegant idea, rarely worth it.

Richardson Maturity Model

There’s a model that grades how RESTful your API is, from Level 0 to Level 3.

Level 0 — One URL, one method. Everything goes through a single endpoint.

POST /api  { "action": "getUsers" }
POST /api  { "action": "deleteUser", "id": 3 }

Brutal, but some APIs actually look like this.

Level 1 — You split things into separate resources. /users, /posts. But you’re still using POST for everything.

Level 2 — Now you’re using the right HTTP methods and returning proper status codes. GET for reading, POST for creating, 201 for created, 404 for not found. This is where things start feeling right.

Level 3 — HATEOAS. Responses include links. The full REST vision.

Most APIs in the wild sit at Level 2, and that’s perfectly fine. Level 3 is more academic than practical. When people say an API is “RESTful,” they usually mean it uses resources, proper HTTP methods, and meaningful status codes.

One last thing: frameworks like Express or Spring Boot don’t make your API RESTful. They give you the tools — app.get, app.post, route parameters. But nothing stops you from writing app.get('/deleteUser', ...). REST is a design choice you make, not something a framework enforces.

REST is not the only way. There are alternatives like GraphQL, WebSocket, and SSE, each solving problems REST doesn’t handle well.