2

I often see three different response return types: Flux<T>, ResponseEntity<Flux<T>>, and Flux<ResponseEntity<T>> in MVC style controllers using Spring WebFlux. The documentation explains the difference between ResponseEntity<Flux<T>> and Flux<ResponseEntity<T>>. Does Spring automatically wrap Flux<T> as either ResponseEntity<Flux<T>> or Flux<ResponseEntity<T>>? if yes, which one?

Moreover, how to decide which one to return, ResponseEntity<Flux<T>> or Flux<ResponseEntity<T>>? What situation or use case would call for using one over the other?

And, from a webclient's point of view, are there any significant differences when consuming the two types of response?

Buck
  • 471
  • 3
  • 9

1 Answers1

4

Does Spring automatically wrap Flux as either ResponseEntity<Flux> or Flux<ResponseEntity>? if yes, which one?

Spring will automatically wrap that Flux as a ResponseEntity<Flux>. For example if you have a web endpoint as follows

@GetMapping("/something") public Flux handle() { doSomething() }

And if you are consuming from a WebClient, you can retrieve your response as either ResponseEntity<Flux<T>> or Flux<T>. There is no default, but I would think it's good practice to retrieve only Flux unless you explicitly need something from the ResponseEntity. The Spring doc has good examples of this.

You actually can consume it as a Flux<ResponseEntity<T>>, but this would only be applicable for more complex use cases.

Moreover, how to decide which one to return, ResponseEntity<Flux> or Flux<ResponseEntity>? What situation or use case would call for using one over the other?

It really depends on your use case.

Returning ResponseEntity<Flux<T>> is saying something like,

I am returning a Response of a Collection of type T objects.

Where Flux<ResponseEntity<T>> is saying something more like

I am returning a Collection of Responses, where the responses have an entity of type T.

Again, I think in most use cases returning just Flux<T> makes sense (This is equivalent to returning ResponseEntity<Flux<T>>)

And finally

And, from a webclient's point of view, are there any significant differences when consuming the two types of response?

I think what you're trying to ask is whether you should be using ResponseEntity<Flux<T>> or Mono<ResponseEntity<T>> when consuming from the WebClient. And the spring doc answers this question quite elegantly

ResponseEntity<Flux> make the response status and headers known immediately while the body is provided asynchronously at a later point.

Mono<ResponseEntity> provides all three — response status, headers, and body, asynchronously at a later point. This allows the response status and headers to vary depending on the outcome of asynchronous request handling.

seoboss
  • 126
  • 4
  • very clear explanations, thanks. To clarify my question on webclient: Is the webclient code for consuming `Flux>` any different from those for consuming `ResponseEntity>`? – Buck Jan 24 '22 at 06:32
  • Yes they will be different. As stated in the original answer: `ResponseEntity make the response status and headers known immediately while the body is provided asynchronously at a later point.` `Mono provides all three — response status, headers, and body, asynchronously at a later point....` In other words, with ResponseEntity> your response status and headers will be obtained synchronously by the ResponseEntity object, where with Flux> you will be provided a Flux that provides the response status, header, and body all at once. – seoboss Jan 24 '22 at 19:26
  • I got this error when I'm using Flux> ```java.lang.IllegalArgumentException: Only a single ResponseEntity supported at org.springframework.util.Assert.isTrue(Assert.java:121) ~[spring-core-5.3.24.jar:5.3.24] Suppressed: reactor.core.publisher.FluxOnAssembly$OnAssemblyException: ``` – Nisha Dec 22 '22 at 08:59
  • A flux returns multiple objects, where it looks like a function you are calling is expecting 'a single ResponseEntity'. What is the code snippet you are running? – seoboss Dec 23 '22 at 00:53