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.
As of Spring Framework 5.3.11, support for RxJava 1 and 2 has been discontinued in accordance with RxJava end-of-life guidelines and upgrade guidelines to RxJava 3.
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.