Spring Web Reactive | 6. Reactive Libraries
spring-webflux depends on reactor-core and uses it internally to compose asynchronous logic and provide Reactive Streams support. WebFlux APIs generally return Flux or Mono, and can accept any Reactive Streams Publisher implementation as input. The distinction between Flux and Mono is important because it expresses cardinality: whether one or multiple asynchronous values are expected. This is essential when deciding how to encode or decode an HTTP message.
For annotated controllers, WebFlux transparently adapts to the reactive library selected by the application. This is handled by ReactiveAdapterRegistry, which provides pluggable support for reactive libraries and other asynchronous types. The registry includes support for RxJava 2/3, RxJava 1 through its Reactive Streams bridge, and CompletableFuture, and you can register additional adapters.
RxJava 1 support is deprecated as of Spring Framework 5.3.
For functional APIs, such as functional endpoints and WebClient, the general WebFlux API rules apply: return Flux or Mono, and accept a Reactive Streams Publisher as input. If a Publisher comes from a custom or different reactive library, it is treated only as a stream with unknown 0..N semantics. If you know its semantics, wrap it with Flux or Mono.from(Publisher) instead of passing the Publisher directly.
For example, if you provide a Publisher rather than a Mono, the Jackson JSON message writer expects multiple values. If the media type represents an infinite stream, such as application/json+stream, values are written and flushed individually. Otherwise, values are buffered and rendered as a JSON array.