Return Values

See equivalent in the Servlet stack

The following table shows the supported controller method return values. Note that reactive types from libraries such as Reactor, RxJava, or other are generally supported for all return values.

For return types like Flux, when multiple values are expected, elements are streamed as they come and are not buffered. This is the default behavior, as keeping a potentially large amount of elements in memory is not efficient. If the media type implies an infinite stream (for example, application/json+stream), values are written and flushed individually. Otherwise, values are written individually and the flushing happens separately.

If an error happens while an element is encoded to JSON, the response might have been written to and committed already and it is impossible at that point to render a proper error response. In some cases, applications can choose to trade memory efficiency for better handling such errors by buffering elements and encoding them all at once. Controllers can then return a Flux<List<B>>; Reactor provides a dedicated operator for that, Flux#collectList().
Controller method return value Description

@ResponseBody

The return value is encoded through HttpMessageWriter instances and written to the response. See @ResponseBody.

HttpEntity<B>, ResponseEntity<B>

The return value specifies the full response, including HTTP headers, and the body is encoded through HttpMessageWriter instances and written to the response. See ResponseEntity.

HttpHeaders

For returning a response with headers and no body.

ErrorResponse

To render an RFC 9457 error response with details in the body, see Error Responses

ProblemDetail

To render an RFC 9457 error response with details in the body, see Error Responses

String

A view name to be resolved with ViewResolver instances and used together with the implicit model — determined through command objects and @ModelAttribute methods. The handler method can also programmatically enrich the model by declaring a Model argument (described earlier).

View

A View instance to use for rendering together with the implicit model — determined through command objects and @ModelAttribute methods. The handler method can also programmatically enrich the model by declaring a Model argument (described earlier).

java.util.Map, org.springframework.ui.Model

Attributes to be added to the implicit model, with the view name implicitly determined based on the request path.

@ModelAttribute

An attribute to be added to the model, with the view name implicitly determined based on the request path.

Note that @ModelAttribute is optional. See “Any other return value” later in this table.

Rendering

An API for model and view rendering scenarios.

FragmentsRendering, Flux<Fragment>, Collection<Fragment>

For rendering one or more fragments each with its own view and model. See HTML Fragments for more details.

void

A method with a void, possibly asynchronous (for example, Mono<Void>), return type (or a null return value) is considered to have fully handled the response if it also has a ServerHttpResponse, a ServerWebExchange argument, or an @ResponseStatus annotation. The same is also true if the controller has made a positive ETag or lastModified timestamp check. See Controllers for details.

If none of the above is true, a void return type can also indicate “no response body” for REST controllers or default view name selection for HTML controllers.

Flux<ServerSentEvent>, Observable<ServerSentEvent>, or other reactive type

Emit server-sent events. The ServerSentEvent wrapper can be omitted when only data needs to be written (however, text/event-stream must be requested or declared in the mapping through the produces attribute).

Other return values

If a return value remains unresolved in any other way, it is treated as a model attribute, unless it is a simple type as determined by BeanUtils#isSimpleProperty, in which case it remains unresolved.