Spring MVC & the Request Flow
The DispatcherServlet front controller and the journey of a request from HTTP arrival to JSON response.
On this page
In the last module BookVault booted up and served a hard-coded list from a
@RestController. That worked, but how? How did an HTTP GET become a call to your
Java method, and your returned object become JSON? The answer is Spring MVC, and
understanding its request flow makes everything else in this module click.
One servlet to rule them all
At the heart of Spring MVC is the DispatcherServlet - a single front
controller that receives every incoming request and coordinates what happens
next. You never write it or configure it; Boot's web auto-configuration sets it up.
Guests don't wander the hotel looking for the right department. They speak to one concierge, who knows exactly who handles each request - housekeeping, the kitchen, the spa - routes them there, and brings back the response. The DispatcherServlet is that concierge: every request comes to it, and it dispatches the work to the right controller and returns the result.
The journey of a request
When GET /api/books/978-0134685991 arrives, a precise sequence runs:
- DispatcherServlet receives the request.
- HandlerMapping matches the URL + method to a controller method.
- Argument resolution binds request parts to method parameters.
- Your controller runs and returns a plain Java object.
- An HttpMessageConverter serializes that object to JSON.
- The response goes back to the client.
Step through it:
The browser or another service sends an HTTP request. It arrives at the embedded server and is handed to Spring MVC.
Why this matters
Notice what your controller doesn't do: it never touches the servlet API, never
parses the URL, never writes JSON. It receives an isbn string and returns a Book.
Spring MVC handles the HTTP plumbing on both sides, so your code stays about the
domain, not the protocol.
This separation is why the same BookController could serve JSON, XML, or another
format without changing - the converter, chosen by content negotiation, decides.
You'll see each piece up close through this module.
MVC here means 'web layer', not templates
The name is historical (Model-View-Controller). For a REST API there's no HTML "view" - the "view" is the serialized JSON body. Everything you learn applies whether you render pages or, as BookVault does, return data.
Trace GET /api/books/978-0134685991 returning a Book as JSON. Name which
component (a) decides that BookController.byIsbn is the right method, (b) turns the
978-0134685991 path segment into the method's isbn argument, and (c) turns the
returned Book object into a JSON response body.
What is the role of the DispatcherServlet in Spring MVC?
Key takeaways
- Spring MVC's DispatcherServlet is a single front controller that handles every request; Boot configures it for you.
- A request flows: DispatcherServlet -> HandlerMapping (routing) -> argument resolution -> your controller -> HttpMessageConverter (serialization) -> response.
- Your controller works with plain Java objects and never touches the HTTP/servlet plumbing.
- Content negotiation lets the same controller return JSON (or another format) without code changes.
- For REST APIs the 'view' is just the serialized response body - the MVC name is historical.