Spring MVC Interview Questions

A curated set of Spring MVC interview questions, covering the request lifecycle and the annotations that drive it.

Q: What is the role of the DispatcherServlet?#

The DispatcherServlet is Spring MVC's front controller — the single servlet that receives every incoming HTTP request instead of each URL being handled by its own separate servlet. It delegates to a HandlerMapping to find which controller method should handle the request, invokes that method, and then either hands the result to a ViewResolver for rendering (traditional @Controller) or serializes it directly to the response (@RestController). Centralizing this in one place is what lets cross-cutting concerns — filters, interceptors, exception handling — apply consistently across the whole application.

Q: What's the difference between @Controller and @RestController?#

@RestController is a composed annotation equal to @Controller plus @ResponseBody. In a plain @Controller, a method's return value is treated as a logical view name that a ViewResolver maps to a template to render — the standard model for server-rendered HTML pages. In a @RestController, every method's return value is serialized directly into the HTTP response body (JSON by default, via Jackson), which is what you want for a REST API with no HTML rendering involved.

Q: What's the difference between @RequestMapping and annotations like @GetMapping?#

@GetMapping, @PostMapping, @PutMapping, @DeleteMapping, and @PatchMapping are all specializations of @RequestMapping that fix the HTTP method — @GetMapping("/orders") is shorthand for @RequestMapping(method = RequestMethod.GET, path = "/orders"). They exist purely for readability and are the conventional default; @RequestMapping is still used at the class level to declare a shared base path, or in the rare case where a single method genuinely needs to handle multiple HTTP methods at once.

Q: What's the difference between @PathVariable and @RequestParam?#

@PathVariable extracts a value from a dynamic segment of the URL path itself, e.g. the {id} in /orders/{id}. @RequestParam extracts a value from the query string, e.g. ?status=SHIPPED in /orders/search?status=SHIPPED. Path variables typically identify which resource, while request parameters typically filter, sort, or paginate a collection.

Q: How does Spring MVC handle form validation, and what is BindingResult for?#

Adding @Valid before a @ModelAttribute-bound parameter triggers Bean Validation against the constraints declared on that class (@NotBlank, @NotNull, etc.). If a BindingResult parameter is declared immediately after the validated parameter, any violations are captured there instead of causing an exception, letting the controller check bindingResult.hasErrors() and re-render the same form with error messages. If BindingResult isn't present, a validation failure instead throws MethodArgumentNotValidException, which is the path typically used for @RequestBody-bound JSON APIs, usually handled centrally with @ExceptionHandler/@ControllerAdvice.

Q: What's the difference between a local @ExceptionHandler and a global one declared with @ControllerAdvice?#

An @ExceptionHandler method defined directly inside a controller only catches exceptions thrown by that same controller's own handler methods. @ControllerAdvice (or @RestControllerAdvice, which adds @ResponseBody) applies its @ExceptionHandler methods across every controller in the application, centralizing handling for exception types that are common across the whole app (validation failures, "not found," access denied) instead of duplicating the same logic in every controller. Spring resolves to the most specific applicable handler when more than one could technically match a thrown exception's type.

Q: What is ProblemDetail, and what problem does it solve?#

ProblemDetail is Spring Framework 6's built-in support for RFC 7807 "Problem Details," giving error responses a consistent, standardized JSON shape (type, title, status, detail, plus any custom properties) instead of every application inventing its own bespoke error object. An @ExceptionHandler can return a ProblemDetail directly, and it serializes automatically to that standard shape — useful for a public API where consistency and predictability of the error format matters to client developers.

Q: When would you choose a traditional server-rendered @Controller over building a @RestController API?#

Server-rendered MVC is often the simpler choice for internal tools, admin panels, or applications with modest interactivity needs, where a separate frontend build, CORS configuration, and client-side routing would add complexity without a corresponding benefit. A @RestController API is the right shape when the client and server are genuinely separate concerns — a JavaScript SPA, a mobile app, or another backend service consuming the API — since in those cases HTML rendering is either irrelevant or someone else's responsibility entirely.

Q: How does content negotiation decide what representation a Spring MVC endpoint returns?#

Content negotiation resolves which representation to send back based on the client's Accept header (and which to accept based on Content-Type), using each method's produces/consumes declarations to know what it's capable of serving or accepting. With Jackson on the classpath, JSON is the default representation with no extra configuration; a method can produce more than one format (e.g. both JSON and XML) and let the client's Accept header decide, though in practice most modern REST APIs serve JSON exclusively and never exercise multi-format negotiation.