Backend Routing Explained for Beginners, Step by Step

by Souy Soeng /October 19, 2026

Diagram of a web server router sending GET and POST requests to separate handlers for home, user and login pages

Backend routing is how a web server matches each incoming request to the piece of code that should handle it. When you visit a home page, submit a login form or open a profile, the server uses routing to decide which function builds the response you get back.

This guide starts with why routing exists and then walks through how a router works inside: reading the method and path, checking a list of routes, and running a handler. After that it looks at a real Express app, at how other frameworks do the same job, and at three mistakes beginners often make.

In short

Backend routing connects each incoming request to the code that answers it.
Every request carries a method (such as GET or POST) and a URL path.
The router checks your routes in order and usually stops at the first match.
Handlers can read parameters from the path, so /users/:id works for any user.
Put routes in the right order, add 404 handling, and always specify methods.

Why does one server need routing?

Think about a website you use every day. The home page, the login form and your profile page feel like separate places, but they often all arrive at the same server, and one program may serve every one of them. So when /home, /login and /cart all reach the same machine, the server needs a way to give each request a different answer.

Without a plan, the code turns into one long tangle of if-statements: if the path is this, do that, otherwise check the next thing. Each new page makes it harder to read, and a small change in one place can quietly break something somewhere else.

Routing fixes this by giving every request a clear path to the code written for it. The project stays tidy as it grows, which is why backends are built this way.

Without routing: one giant block of conditions that is hard to change safely
With routing: each request goes straight to the code meant for it

What is backend routing?

Backend routing is the step where a server matches an incoming request to the code that handles it. A simple way to picture it is a receptionist. You explain what you need, and the receptionist sends you to the right desk. The receptionist doesn't solve your problem. They only know where it should go.

The router plays that receptionist role. Your browser sends a request to the web server, and the router reads it and decides where it goes. A request for the home page goes to the home handler, a profile request goes to the user handler, and a sign-in goes to the login handler.

The handler is the function that does the actual work. It might fetch data or check a password, and then it builds the response that goes back to the browser. To sum up: the router decides, and the handler answers.

Router: matches each request to its handler
Handler: the function that builds the response

Why routing keeps growing apps manageable

A real website asks its server to do many different jobs all day long. One server might handle the home page, logging in, viewing a user, creating a post, deleting a post and running a search. Each of these jobs needs different code.

Without routing, all of that logic would be squeezed into a single function. With routing, each action gets its own route and its own small function. That separation pays off in two practical ways.

First, debugging gets easier: if search breaks, you know exactly which function to look at. Second, adding a page is simple. You add one new route without touching the others, so existing features stay safe while the app grows.

How does a router work? Method plus path

Routing happens in three steps, and the first is that a request arrives. Every request carries two key pieces of information: a method and a URL path. Those two values are all the router needs to start.

The method says what you want to do. GET means you want to read something, and POST means you are sending something new. The path says where, such as /users/42.

Here are two requests making the round trip. A browser sends GET /users/42 to read a user's page, and the server replies 200 OK with that page. Then a login form sends POST /login, and the server replies 200 OK, logged in. In both cases the method and path together are what the router checks next.

GET /users/42 → 200 OK, user page
POST /login → 200 OK, logged in

How the router compares routes in order

In step two, the router takes the method and path and compares them against the list of routes you defined, one at a time, until one matches. It works like checking names on a guest list from top to bottom.

Take the request GET /users/42 and a small route list. Route 1 is GET /, which doesn't match because the path is different. Route 2 is POST /users, which doesn't match because the method is wrong. Route 3 is GET /users/:id, and that one matches, so the router runs showUser.

Two rules come out of this example. Order matters, because most routers stop at the first match, so the order you write routes in decides which one wins. And both parts must match: a GET to /users and a POST to /users are two separate routes with two separate handlers.

Most routers stop at the first matching route
Same path with a different method is a different route

Route parameters: how /users/:id works

In step three, the matching handler runs. Before it does, the router often pulls parameters out of the path, such as an ID. Parameters let one route serve many different pages without repeating code.

Here is how that works. The route pattern is /users/:id and the request path is /users/42. Lining the two up gives the parameter id = 42. The router calls showUser with 42, and the response is the page for user 42.

The colon in :id tells the router to capture whatever sits in that position and pass it to the handler. User 7, user 42 or any other user goes through the same route, so you write the code once instead of once per user.

Backend routing in a real Express app

Express is a popular JavaScript framework, and this small app uses all three steps covered above. You can read it like a list of routes from top to bottom. First the app is created. Then app.get('/') sends the home page, and app.get('/users/:id') sends back the ID taken from req.params.

Next, app.post('/login') hands login requests to a function, and app.listen starts the server on port 3000. GET / is about the simplest route you can write: a method, a path and a small handler.

Two details are worth noticing. req.params.id holds the value the router captured from the path, so visiting /users/42 gives 42. And POST /login only runs for POST requests. A plain GET to the same path won't trigger it, which is the behaviour you want for a login.

GET /: answers a visit to the home page
req.params.id: holds the ID taken from the path
POST /login: runs only when a form sends data

const app = express();
app.get('/', (req, res) => res.send('Home'));
app.get('/users/:id', (req, res) =>
  res.send('User ' + req.params.id));
app.post('/login', handleLogin);
app.listen(3000);

How routing works in Express, Django, Flask and Rails

Web frameworks include routing, and it is the backbone of how developers build APIs. The vocabulary changes from one framework to the next, but the idea stays the same: match a request to a handler.

Express, for JavaScript on Node.js, uses app.get with a path and a handler function. Django, a Python framework, keeps its routes together in a URLs file that maps each path to a view, which is Django's name for a handler. Flask, a lighter Python option, puts a short route line directly above each function, so the path and its code sit side by side.

Rails, for Ruby, keeps every route in one routes file and sends each one to a controller action. Once you understand routing in one framework, the concept carries across to the others.

Express: JavaScript on Node.js
Django: Python, routes listed in a URLs file
Flask: Python, a route line above each function
Rails: Ruby, all routes in one routes file

Common backend routing mistakes to avoid

A typical beginner bug looks like this. You request /users/new and the wrong page loads. The cause is that /users/:id was listed first, so it caught the request and treated the word "new" as the ID. Because overlapping routes are checked top to bottom, specific routes like /users/new need to come before general routes with parameters.

The second mistake is having no 404 handling. When no route matches, add a catch-all that clearly says "not found" instead of returning a confusing error or a blank page.

The third is ignoring methods. If a route accepts any method, a simple GET request could change or delete data. Always state which method each route expects.

Wrong route order: put specific routes before general ones
No 404 handling: give unknown paths a clear "not found"
Ignoring methods: GET and POST on one path are not the same

Key takeaways

Backend routing matches each request to the code that handles it.
Every request brings a method plus a path.
The router checks routes in order and stops at the first match.
Handlers read parameters like IDs to build the right response.
Order routes carefully, handle 404s and respect methods.

Frequently asked questions

What is the difference between a router and a handler?

The router reads an incoming request and decides which code should answer it. The handler is that code: a function that does the work, such as fetching data or checking a password, and builds the response.

What does the colon mean in a route like /users/:id?

The colon marks a route parameter. It tells the router to capture whatever is in that part of the path and pass it to the handler, so /users/42 gives the handler an id of 42.

Why does the order of routes matter?

Most routers check routes from top to bottom and stop at the first match. If a general route like /users/:id comes before /users/new, it will catch that request and treat "new" as an ID.

Can two routes have the same path?

Yes, as long as they use different methods. A GET to /users and a POST to /users are separate routes with separate handlers, because the router matches both the method and the path.

What should happen when no route matches a request?

Add a catch-all that returns a clear "not found" response, the familiar 404. That way unknown paths get a helpful answer instead of a confusing error or a blank page.

Do all web frameworks handle routing the same way?

The idea is the same everywhere, but the details differ. Express uses app.get and app.post, Django lists routes in a URLs file, Flask puts a route line above each function, and Rails keeps routes in one routes file.

Watch the full video on YouTube →

Tag

Ad