Spring Boot interview questions: Spring Web and REST APIs

@RestController is a composed annotation that is meta-annotated with @Controller and @ResponseBody. Marking a class with it means each handler method's return value is serialized into the response body (for example as JSON) rather than being resolved as a view name. @RequestBody binds an incoming request body to a method parameter, @Service marks a service-layer bean, and @RequestMapping maps URLs to handlers without changing how return values are written.

DispatcherServlet is the front controller and receives every request first. The handler mapping (RequestMappingHandlerMapping) then uses the HTTP method and path to select the getUser method. Before that method can be invoked, the handler adapter resolves its parameters, including extracting 42 from the {id} template variable for @PathVariable Long id. The method then executes and returns a User. Finally, because @RestController implies @ResponseBody, a message converter such as Jackson writes the object as JSON into the response body. Each step consumes the previous step's output, so the sequence is a strict total order.

@RestController is defined as @Controller plus @ResponseBody, so every handler method's return value is written directly to the response body. @GetMapping is a specialised form of @RequestMapping that fixes the HTTP method to GET. Class-level and method-level mapping paths are concatenated, so a class mapped to /api with a method mapped to /users serves /api/users. The statement about a returned String being resolved as a view name is false, because the @ResponseBody semantics bypass view resolution. The statement about @PathVariable is false, because it binds URI template variables such as {id} in the path, while @RequestParam handles query parameters.

The class-level @RequestMapping("/api/users") is combined with the method-level @GetMapping("/{id}"), so the handler is mapped to the pattern /api/users/{id}. The request path /api/users/42 matches that pattern with id bound to 42 (a long). Because @RestController serializes the String return value directly as the body, the method returns "user " + 42, which is the text user 42. The listUsers method is mapped to /api/users alone and does not match this request.

@RestController is a meta-annotation that is itself annotated with @Controller and @ResponseBody. The @ResponseBody part tells Spring MVC to pass each handler method's return value through an HttpMessageConverter (for example, Jackson for JSON) and write it to the response body, instead of resolving it as a view name. The bean scope stays singleton by default, component scanning is governed by @SpringBootApplication or @ComponentScan, and request mappings are only set by annotations such as @GetMapping or @RequestMapping, so none of the other options describe what the annotation adds.

The statement is false. When the method attribute of @RequestMapping is omitted, the mapping matches every HTTP method (GET, POST, PUT, DELETE, and so on) for the given path. Restricting a handler to a specific verb requires setting method explicitly, or using a shortcut annotation such as @GetMapping, which sets the method implicitly. The path is only one part of the match; the HTTP method is not defaulted to GET.

The method-level mapping declares the template variable orderId, but @PathVariable on the parameter id has no explicit name, so Spring looks for a path variable called id. That variable does not exist in the template, so argument resolution throws a missing-path-variable exception and the request ends with a server error before orderService.findById is invoked. The fix is @PathVariable("orderId") Long id (or renaming the parameter to orderId). The other options are wrong: a @RestController can return a plain object, class-level and method-level mappings combine normally, and @PathVariable is fully supported in REST controllers.

Both patterns match the request path /users/me, so the dispatcher must choose one. Spring MVC's pattern comparator (PathPattern.SPECIFICITY_COMPARATOR in Spring 5.3 and later, which is the default in Spring Boot 3) prefers patterns with more literal characters and fewer captured variables, so the literal segment 'me' outranks the variable segment '{id}'. The handler for /users/me is therefore selected, and the method declaration order in the class has no effect on this choice.

@RestController is meta-annotated with @Controller and @ResponseBody, so every handler's return value is written directly to the response body instead of being resolved as a view name. For request mapping, consumes restricts a handler to requests whose Content-Type header matches the declared media types, and produces restricts it based on what the client's Accept header permits. These two headers are the ones Spring compares against those attributes, so the blanks are ResponseBody, Content-Type and Accept respectively.

Before Spring Framework 6.0, trailing slash matching was on by default, so a mapping to /users also matched /users/. Spring 6.0 turned this off by default as part of moving toward PathPatternParser and away from suffix/trailing matching, which is why the same controller behaves differently after upgrading to Spring Boot 3. The card asks for the observable behavior plus the configuration default that causes it, and the back gives both, so the answer is fully determined by the default setting of the current major version.