Reactive libraries

spring-webflux depends on reactor-core and uses it internally to formulate asynchronous logic and provide support for Reactive Streams. Typically, WebFlux APIs return Flux or Mono (since they are used internally) and look ahead to any Publisher implementation from the Reactive specification. Streams. The use of Flux versus Mono is important because it helps express the power of a set—for example, whether one or more asynchronous values are expected, which can be important for decision making (e.g. when coding or decoding HTTP messages).

With annotated controllers, WebFlux easily adapts to the reactive library chosen by the application. This is done using ReactiveAdapterRegistry, which provides pluggable support for the reactive library and other asynchronous types. The registry has built-in support for RxJava 3, Kotlin and SmallRye Mutiny coroutines, but you can register other third-party adapters.

For functional APIs (such as functional endpoints, WebClient and others), the rules common to the WebFlux APIs apply - Flux and Mono are used in as return values, and Publisher from the Reactive Streams specification as input. When a Publisher is provided, whether a custom one or from another reactive library, it can only be taken to be a stream with unknown semantics (0..N). If, however, the semantics are known, you can wrap it with Flux or Mono.from(Publisher) instead of passing the raw Publisher.

For example, if you have a Publisher that is not Mono, the Jackson JSON message writer accepts multiple values. If the media type is an infinite stream (for example, application/json+stream), the values are written and reset individually. Otherwise, the values are buffered into a list and output as an array in JSON format.