DispatcherServlet & Request Flow

Trace a request step by step through DispatcherServlet, handler mapping, a controller, and the view resolution process.

Introduction

You now know that DispatcherServlet sits at the center of every Spring MVC request as the front controller. This lesson walks through exactly what happens between the moment a request arrives and the moment a response is sent back, step by step.

What You Will Learn

The precise role DispatcherServlet plays
Each step a request passes through: mapping, adapting, executing, resolving
How a controller's return value becomes an actual HTTP response
How Spring Boot configures DispatcherServlet automatically

DispatcherServlet: The Front Door

DispatcherServlet is itself a regular Java servlet, registered to handle incoming HTTP requests, typically for every URL in the application. Instead of processing the request itself, it delegates the real work to a series of collaborating components, coordinating them into a consistent pipeline.

Step-by-Step Request Flow

1. The client sends an HTTP request, which arrives at DispatcherServlet.
2. DispatcherServlet asks a HandlerMapping which controller method matches the request URL and HTTP method.
3. DispatcherServlet obtains a matching HandlerAdapter, which knows how to invoke that specific type of handler.
4. The HandlerAdapter invokes the controller method, passing in resolved arguments (path variables, request body, and so on).
5. The controller method returns a result: a view name, a ModelAndView, or a response body for a @RestController.
6. If a view name was returned, DispatcherServlet asks a ViewResolver to turn it into an actual View.
7. The View renders the model data (or, for a REST response, the body is already written directly).
8. DispatcherServlet sends the completed response back to the client.

A Full Example

Consider a controller that returns data directly as JSON, which is the most common style for modern REST APIs.

ProductController.java

@RestController
@RequestMapping("/products")
public class ProductController {

    @GetMapping("/{id}")
    public Product getProduct(@PathVariable Long id) {
        return new Product(id, "Wireless Mouse", 25.99);
    }
}

Product.java

public class Product {
    private final Long id;
    private final String name;
    private final double price;

    public Product(Long id, String name, double price) {
        this.id = id;
        this.name = name;
        this.price = price;
    }

    public Long getId() { return id; }
    public String getName() { return name; }
    public double getPrice() { return price; }
}

GET /products/1

Click Run to see what this code prints.

Because @RestController implies @ResponseBody, DispatcherServlet skips the ViewResolver step entirely for this request. Instead, a HttpMessageConverter (typically backed by Jackson) serializes the returned Product object straight into the JSON response body.

Where Spring Boot Fits In

In a plain Spring MVC application, you would register DispatcherServlet by hand, either in web.xml or through a WebApplicationInitializer. Spring Boot removes that ceremony: adding spring-boot-starter-web automatically configures and registers DispatcherServlet on an embedded servlet container, mapped to handle every request out of the box.

Common Mistakes

Avoid These Mistakes

Assuming every controller method result goes through a ViewResolver; @RestController responses skip that step entirely.
Expecting DispatcherServlet to execute business logic itself; its job is coordination, not the actual work.
Forgetting that a HandlerMapping failure (no matching controller) results in a 404 before a controller method ever runs.
Not understanding that a thrown exception can be routed to a dedicated error-handling flow instead of propagating as a raw stack trace to the client.

Best Practices

Rely on Spring Boot's auto-configuration for DispatcherServlet instead of registering it manually unless you have a specific reason not to.
Keep controller methods focused on translating requests to service calls and results to responses, not more.
Use precise request mappings (HTTP method plus path) so HandlerMapping can route requests unambiguously.
Understand the flow well enough to know where to add cross-cutting behavior, such as an AOP aspect or a filter, if you need it.

Frequently Asked Questions

Does every request in a Spring Boot app go through DispatcherServlet?

Yes, by default it is mapped to the root path "/" and handles every incoming request, delegating to the appropriate controller or returning an error response if none matches.

What decides which controller method handles a request?

HandlerMapping, which matches the request's URL and HTTP method against the @RequestMapping-family annotations (@GetMapping, @PostMapping, etc.) declared on your controllers.

What happens if no controller matches the request?

DispatcherServlet returns a 404 response, since no HandlerMapping was able to resolve a handler for that URL.

Key Takeaways

DispatcherServlet is the single front controller every Spring MVC request passes through.
A request flows through HandlerMapping, a HandlerAdapter, the controller method, and, for view-based responses, a ViewResolver.
@RestController responses skip view resolution and are serialized directly by a message converter.
Spring Boot auto-configures and registers DispatcherServlet for you.
Understanding this flow helps you reason about where to hook in cross-cutting behavior.

Summary

DispatcherServlet ties together handler mapping, controller execution, and view resolution into one coherent request-handling pipeline, and understanding that pipeline makes debugging routing issues and designing new endpoints far more intuitive. With the core Spring MVC request flow understood, you are ready to build on it with a deeper look at how Spring MVC resolves views and renders responses.

Next Lesson →