What are the implications of using @RestController for data serialization?

@RestController tells Spring to serialize every handler method's return value directly into the HTTP response body — typically as JSON via Jackson — rather than treating it as a logical view name. This shapes both how simple API code becomes and what the controller can no longer do.

Key Points: • Return values are converted automatically by an HttpMessageConverter (Jackson for JSON by default), so no @ResponseBody is needed on each method. • Serialization format depends on the Accept header and configured converters, most commonly JSON, but XML is possible with the right converter on the classpath. • Because there's no view resolution step, a @RestController method can't return a logical view name to render an HTML page. • Field visibility, naming, and null handling in serialized objects can be controlled with Jackson annotations like @JsonIgnore or @JsonProperty. • Exception handling for serialization errors or bad input is commonly centralized with @ControllerAdvice and @ExceptionHandler, returning structured error JSON instead of an HTML error page.

Example: A method returning a Product object from a @RestController is automatically serialized to {"id":1,"name":"Widget","price":9.99} in the response body, with no manual JSON conversion code required.

Interview Tip: A concise interview answer is:

"@RestController means every return value gets serialized straight into the response body by an HttpMessageConverter, usually Jackson producing JSON, which is what makes it ideal for APIs. The tradeoff is that the same controller can't return a view name for HTML rendering, so mixed API-and-page apps typically split those concerns into separate controllers."