Spring MVC — the 21 you've got wrong

void, String, ModelAndView, Model — servlet objects are parameters

Spring injects the servlet objects so you can read from them. Returning one tells the framework nothing about what to render:

@GetMapping("/hello")
public String hello(HttpServletRequest request,      // ← injected IN
                    HttpServletResponse response,    // ← injected IN
                    HttpSession session) {           // ← injected IN
    log.info(request.getRemoteAddr());
    return "helloView";                              // ← a view NAME comes OUT
}

The parameter side is worth knowing as its own fact, because it's the mirror question. Spring can inject: HttpServletRequest/Response, HttpSession, Model, Locale, Principal, HttpMethod, InputStream/Reader, BindingResult, and anything annotated @PathVariable/@RequestParam/@RequestBody/@RequestHeader/@ModelAttribute.

If you take the response as a parameter and write to it yourself, return void. That's the supported way to handle the response by hand — not returning the response object.

An absolute path to the view — a logical name and void are both fine

A returned String is always treated as a logical name, so the resolver's prefix and suffix are applied to whatever you give it:

That third row is the key, and it's what makes the question fair: if you genuinely need a physical path, wrap it in a View. The rule is "a String is a name; a View is a location."

Two special String prefixes are the exception that proves it — "redirect:/home" and "forward:/other" are recognised by the resolver and handled specially rather than resolved as names.

String, View, ModelAndView (and void) — bare Object cannot

The question is narrower than "what's a valid return type" — it asks specifically what the view pipeline can consume. ResponseEntity and domain objects are valid returns but never reach a ViewResolver; they go down the message-conversion path instead.

Watch for that narrowing in the stem: "so that ViewResolver can resolve a View" restricts the answer to master table 1's first five rows.

@RequestBody is input only; @ResponseBody is the output annotation

A matched pair pointing in opposite directions:

@PostMapping("/products")
public @ResponseBody Product create(@RequestBody Product incoming) { … }
//     ^^^^^^^^^^^^^ OUT              ^^^^^^^^^^^^ IN

Both use the same machinery — HttpMessageConverters — just in opposite directions. Jackson deserialises the incoming JSON and serialises the outgoing object.

Two different failures: one won't compile, the other fails at runtime

A correction to the source material: its explanation says the second one "should be @PathVariable("id") or @PathVariable String id". Only the latter fixes it — @PathVariable("id") alone still leaves the parameter with no type, so it still won't compile. Worth knowing, because the two failure modes are miles apart.

And the rule the fourth signature tests: the name in @PathVariable("…") must match a variable in the URI template, not the Java parameter name. Template {employeeId} plus @PathVariable("id") is a mismatch.

@Controller + @ResponseBody — which makes an explicit @ResponseBody redundant

The source is two lines:

@Target(ElementType.TYPE)
@Controller          // it's a controller bean
@ResponseBody        // every method writes to the response body
public @interface RestController { … }

So inside a @RestController, a method-level @ResponseBody is harmless but redundant. And @RequestMapping is not part of it — you still declare mappings yourself.

The consequence worth memorising, because it was missed in both #3 and #4:

A String is handled by StringHttpMessageConverter, which writes it verbatim. Only non-String objects reach Jackson and become JSON. Returning a String from a REST controller does not produce a JSON string.

Mixed controllers: if some methods return views and others JSON, use @Controller and put @ResponseBody on the individual JSON methods. @RestController is all-or-nothing.

An architectural style — stateless, uniform, cacheable, layered, interoperable

The six constraints these questions are drawn from:

"Style, not protocol" is the other stock answer: REST is a set of constraints, HTTP is the protocol it rides on. SOAP by contrast is a protocol — envelope format, WSDL contract, specification. That comparison is what these questions are usually building toward.

And the verb semantics, which pair with it constantly:

Safe = doesn't change state. Idempotent = doing it twice has the same effect as once. That's why the bank's Q1 says GET is right for a find and 201 is wrong for a retrieval — 201 means "created".

It coordinates and produces the response — it never resolves views or calls a View directly

The registration fact, which was #8's fourth option: @EnableWebMvc does not register a DispatcherServlet. It only switches on the MVC infrastructure beans. The servlet is registered by Boot's auto-configuration (mapped to /) or by hand in web.xml / a WebApplicationInitializer.

And from #1: the DispatcherServlet never goes straight to a View. It always goes through a handler first — that indirection is what makes it a front controller rather than a router.

@RequestBody — @RequestMapping only maps the URL

Keep the four apart by which part of the request each one reads — that's master table 3, repeated because it's worth over-learning:

The distractors in that question were a Jackson annotation (@JsonDeserialize, which customises how a type deserialises, not where the data comes from) and an invented one (@RequestDeserialize). Combine @RequestBody with @Valid for bean validation, and note the body stream can only be read once.

Pass an HttpEntity holding HttpHeaders to exchange()

Why headers can't live on the template: RestTemplate is thread-safe once configured and normally a shared singleton bean. A per-request value stored on it would leak across threads — one user's token on another user's call. Per-request state must travel with the call.

HttpHeaders headers = new HttpHeaders();
headers.setBearerAuth(token);
headers.setContentType(MediaType.APPLICATION_JSON);

HttpEntity<Void> entity = new HttpEntity<>(headers);      // headers only, no body

ResponseEntity<User> res = restTemplate.exchange(
        "/users/{id}", HttpMethod.GET, entity, User.class, 1);

Why exchange() specifically: the convenience methods have no header slot — getForObject(url, Class) and postForObject(url, body, Class) take no HttpEntity. If a question involves custom headers, the answer involves exchange().

The direction trap: @RequestHeader is server-side — it reads an incoming header in a controller. HttpEntity is client-side — it writes an outgoing one. The exam pairs them because both contain "header" and they point opposite ways.

The entity family: HttpEntity (headers + body) → RequestEntity adds method + URL; ResponseEntity adds the status code.