what is the difference between ResponseEntity<Mono> and Mono<ResponseEntity> as a return type of a rest controller

Question

In Spring Webflux, what's the difference between ResponseEntity<Mono> versus Mono<ResponseEntity> as a return type of a rest controller?

When is the most appropriate to what?

Following up on this question, let's say I need to return a list, or let's say several elements of Foo, there are many examples of returning Flux. Would it make sense to return ResponseEntity<Flux> or Flux<ResponseEntity>?

When I'm looking for this question, I found the same question posted here: https://github.com/spring-projects/spring-framework/issues/22614, but no answer, I searched spring docs, but find no info.

Vacua

The first returns a ResponseEntity that itself includes a Mono. The other is the reactive way of returning a ResponseEntity. The flux sample returns a ResponseEntity that writes a Flux, the other returns a Flux or ResponseEntity instances. – Sinusoid

Answer 1

Here are the various options you can make with a ResponseEntity return value:

• ResponseEntity<Mono<T>> or ResponseEntity<Flux<T>> -- this makes the response status and headers known immediately while the body is provided asynchronously at a later point. Whether the body is Mono or Flux depends on how many values the response has.
• Mono<ResponseEntity<T>> -- this provides all three -- response status, headers, and body, asynchronously at a later point. IT allows the response status and headers to vary depending on the outcome of asynchronous request handling.
• Mono<ResponseEntity<Mono<T>>> or Mono<ResponseEntity<Flux<T>>> are also possible but less common. They provide the response status and headers asynchronously first and then the response body, also asynchronously at a second point later.

Ineluctable

This was insightful, great answer! However, it is quite confusing in practice. Do you know of any examples which demonstrate the understanding you share in a real world project. I'm dabling with open api generator for Spring Boot using reactive option to create the interface stubs to be implemented. Return signatures are: Mono<ResponseEntity<Game>>, Mono<ResponseEntity<Void>>, Mono<ResponseEntity<Flux<ContactDTO>>> (most confusing, is this even accurate in your opinion/experience?). Thanks very much! – Melisandra

I think that the default return type in the Controller, if you do not specify the ResponseEntity, for example Mono<String> is ResponseEntity<Mono<String>>(option 1) – Arriviste

Answer 2

https://docs.spring.io/spring-framework/docs/current/reference/html/web-reactive.html#webflux-ann-responseentity

WebFlux supports using a single value reactive type to produce the ResponseEntity asynchronously, and/or single and multi-value reactive types for the body.

So the return type on an annotated controller would actually be a Reactive Publisher like Flux or Mono that emits an object representing the data to return.

Example

Flux<AccountDto>

Or also:

Flux<ResponseEntity<AccountDto>>

I think you can even just set a raw DTO type as the return type and Webflux will automagically wrap it in a publisher for you.

Valid Return Types

https://docs.spring.io/spring-framework/docs/current/reference/html/web-reactive.html#webflux-ann-return-types

Example: https://github.com/oktadeveloper/okta-spring-webflux-react-example/blob/react-app/reactive-web/src/main/java/com/example/demo/ProfileRestController.java

Non-blocking Reactive Paradigm

When doing Reactive Programming you want to every layer to communicate via Flux/Mono. So you would get back a Flux from your ReactiveRepository and the service layer would also return a Flux to the Controller. Basically, in reactive programming everything is a Flux/Mono.

Internals

While SpringMVC and Spring Webflux annotated controllers look similar, they are vastly different internally. For instance, Webflux uses Jetty while SpringMVC uses Tomcat by default. Internally, Webflux is more like a non-blocking event-loop architecture while SpringMVC traditionally leverages a threadpool with 1 thread per request blocking for I/O.

Check out this article for more details on Spring WebFlux

Gupta