@RestController vs @Controller.

Hook: Interviewers love this question because one annotation decides whether Spring sends JSON right back or starts hunting for an HTML page.

Question: What is the difference between @RestController and @Controller in Spring Boot?

Answer: @Controller is usually used for Spring MVC pages: by default, Spring treats the returned value as a view name and tries to render a template. @RestController is a shortcut for @Controller plus @ResponseBody, so every handler method writes its return value directly to the HTTP response body, usually as JSON. For REST APIs, that means less boilerplate and fewer view-resolution bugs.

Interview-Ready Answer: “I use @Controller when I want Spring MVC to return a view, like an HTML page, and I add @ResponseBody only on methods that should return raw data. @RestController is basically @Controller plus @ResponseBody on every method, so it’s the right choice for REST APIs. The big gotcha is that if I return a plain String from @Controller without @ResponseBody, Spring treats it as a view name, not text.”

What is really happening?

Detailed Explanation: @Controller is the classic Spring MVC annotation for request-handling classes. By default, Spring assumes the returned value is meant for view rendering, so a returned String is interpreted as a logical view name. A view resolver is the part of Spring that turns that logical name into a real page, such as a Thymeleaf template. @RestController is a meta-annotation, meaning an annotation built on top of another annotation; it combines @Controller and @ResponseBody, so Spring writes every method return value directly to the HTTP response body instead of looking for a view.

Under the hood, step by step

1. The request enters DispatcherServlet, which is Spring MVC’s front controller.
2. Spring finds the matching handler method using request mappings such as @GetMapping.
3. If the method is in @Controller and does not have @ResponseBody, Spring treats the return value as a view name and asks a view resolver to render HTML.
4. If the method is marked with @ResponseBody or lives inside @RestController, Spring skips view resolution.
5. Instead, a message converter (a component that turns objects into HTTP bytes, such as JSON or plain text) serializes the return value.
6. The result is written to the response body, and Spring chooses the content type through content negotiation, which means matching the response format to the client’s Accept header and the available converters.

Quick comparison

Annotation	Default return meaning	Typical use
@Controller	View name	HTML pages
@Controller + @ResponseBody	Body for selected methods	Mixed MVC/API
@RestController	Body for all methods	REST APIs

When to use each

• Use @RestController for JSON APIs, mobile backends, microservices, and simple data endpoints.
• Use @Controller when you render pages and pass data into templates like Thymeleaf or JSP.
• Use ResponseEntity with either one when you need to set status codes, headers, or cookies explicitly.

Performance and edge cases

The annotation choice itself has no meaningful runtime cost; routing is effectively O(1) and the response work is usually O(n) in the size of the data being rendered or serialized. In practice, JSON serialization with Jackson is often very fast for small DTOs, usually taking only a few milliseconds or less, while template rendering adds extra view lookup and page rendering work. The biggest real cost is usually payload size, network time, and client parsing, not the annotation.

Important gotchas: a plain String from @Controller is a view name, not body text; @RestController does not mean “JSON only” because it can also return plain text or bytes; and mixed page-plus-API controllers are possible, but they are easier to misunderstand and harder to maintain.

Real-World Story: Imagine an e-commerce checkout service with a /api/orders/{id} endpoint used by a mobile app. A developer copies a page controller, forgets @ResponseBody, and returns an OrderDto from @Controller. In production, Spring tries to treat the DTO result like a view name, so the client receives an HTML error page or a 500 response instead of JSON. The mobile app then fails to parse the response, and logs show messages like “Could not resolve view” or a content-type mismatch. The fix is simple: change the class to @RestController or add @ResponseBody to the API method.

That bug is nasty because the code looks innocent, but the symptoms show up far away: users see broken screens, API consumers report JSON parsing errors, and the server logs point to view resolution rather than business logic.

Follow-up & Tricky Questions:

• When would you choose @Controller over @RestController? Use @Controller when the endpoint returns HTML pages or other server-rendered views. It is the right fit for MVC screens, not pure API responses.
• Can @Controller return JSON? Yes, if you add @ResponseBody to the method or return a ResponseEntity. The class annotation alone does not force view rendering on every method.
• What does @ResponseBody do? It tells Spring to write the method return value straight to the HTTP response body. Spring then uses message converters to turn the object into JSON, text, or bytes.
• Is @RestController just syntax sugar? Yes, for most cases it is shorthand for @Controller + @ResponseBody at the class level. That shorthand is valuable because it makes REST intent obvious and reduces repeated annotations.
• When should I use ResponseEntity? Use it when you need control over status codes, headers, or cookies. @RestController controls how the body is written, but ResponseEntity controls the full HTTP response.
• Can I mix HTML and JSON in one controller? You can, but it is usually clearer to separate them. Mixed controllers are where people most often forget which methods return views and which ones return body data.
• If a @RestController method returns String, is it a view name? No. In a rest controller, that String is sent as the response body, so Spring does not try to resolve a template name.
• Does @RestController force status 200? No. A successful handler method usually ends with 200 by default, but you can return other statuses using ResponseEntity or by throwing mapped exceptions.

Tricky / Gotchas:

• “@RestController means JSON only.” Not exactly. It means the return value goes to the body; the exact format depends on the return type and Spring’s message converters.
• “A plain String from @Controller is text.” Wrong by default. It is a logical view name unless you add @ResponseBody.
• “I can safely put API and page methods together.” Technically yes, but it is easy to misread later. Separate controllers are usually cleaner and safer in real projects.

Common Mistakes:

• Using @Controller for REST and forgetting @ResponseBody. Correction: use @RestController for API classes or add @ResponseBody to each data-returning method.
• Assuming @RestController can only return JSON. Correction: it returns whatever the configured message converters can write, including text and bytes.
• Returning a String from @Controller and expecting text output. Correction: Spring interprets it as a view name unless you opt into body output.
• Forgetting that status and headers are separate concerns. Correction: use ResponseEntity or exception handling when you need more than the body.

Memory Hook: Think: Controller hands you a ticket to a room; RestController hands you the package at the door. Ticket = view name, package = response body.

Cheat Sheet:

• @Controller = Spring MVC pages by default.
• @RestController = @Controller + @ResponseBody.
• @ResponseBody skips view resolution.
• String return in @Controller means view name.
• Use ResponseEntity for status and headers.
• Separate API controllers from page controllers when possible.

Practice Tasks:

• Create one @RestController endpoint that returns a DTO and test it in the browser or Postman.
• Take a @Controller method that returns a String, add @ResponseBody, and observe how the behavior changes.
• Add a missing query parameter to the validation endpoint and confirm that Spring returns HTTP 400.