liveBook · Manning

Routing

As explained in Rust Servers, Services, and Apps

A router is a request-dispatching component that selects a handler based on the characteristics of an incoming request.

Routing decides which handler receives an HTTP request. In a hand-built Rust server, the server reads TCP bytes and converts them into an HTTP request; the router selects a handler; the handler constructs an HTTP response. Keeping these jobs separate gives the router one responsibility: dispatch, not request parsing or response creation. section 2.3

In Actix Web, an application registers routes rather than calling a separate router module directly. Each route pairs a path and HTTP method with a handler function. The application uses the incoming request’s path and method to choose that handler. section 3.1.2 section 3.3

Start with a health check

In src/bin/basic-server.rs, register `cfg.route("/health", web::get().to(health_check_handler))`, then attach the configuration with `App::new().configure(general_routes)`. A GET request to `/health` reaches the handler, which returns a health-check response. section 3.1.1

Listing 4.1 Routes for the tutor web service
use super::handlers::*;
use actix_web::web;
 
pub fn general_routes(cfg: &mut web::ServiceConfig) {
   cfg.route("/health", web::get().to(health_check_handler));
}
 
pub fn course_routes(cfg: &mut web::ServiceConfig) {
  cfg.service(
    web::scope("/courses")
      .route("/", web::post().to(post_new_course))                 #1
      .route("/{tutor_id}", web::get().to(get_courses_for_tutor))  #2
      .route("/{tutor_id}/{course_id}", web::get().to(
      get_course_details)),                                      #3
   );
}

The route listing shows one GET health check and a `/courses` scope with POST and GET handlers, including paths containing `{tutor_id}` and `{course_id}`. section 4.3.1

Group related endpoints under a shared root with `web::scope`. For example, a POST to `/courses/` can reach `new_course` once the route group is registered with the application and the handler is defined. The handler then works with the request data and application state; those are separate from the route’s dispatch decision. section 3.2.4

Check dispatch before implementing behavior

For course maintenance, register POST, PUT, and DELETE routes, then give their handlers temporary responses. Send each request with `curl` and check for its distinct placeholder message. This verifies that requests reach the intended handlers before backend calls are added. section 9.4

Routes also dispatch requests outside a JSON API: `/static` can serve files from disk, while a GET to `/tutors` can reach a handler that fetches data and renders a Tera template. The route selects the work; the service or handler performs it. section 7.2 section 7.7

How Rust Servers, Services, and Apps covers it

How deep it goes
Defines the dispatch responsibility and works through route registration, scopes, path parameters, and checks with placeholder handlers.
Examples
Uses a GET health check, scoped course endpoints, and curl requests against POST, PUT, and DELETE placeholders.
What it assumes
Assumes familiarity with Rust projects and modules while introducing request dispatch through a hand-built HTTP server before Actix routes.
What you can do after
Apply it via Actix Web route configuration and verify that requests reach the intended handlers with curl.
How it connects
Links HTTP methods, handlers, REST APIs, path parameters, and request extractors.

Also explained in

Compare how 22 books explain routing →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Rust Servers, Services, and Apps. The section links point to the parts of the book it draws on.