This part of the documentation covers support for reactive-stack web applications built
on a Reactive Streams API to run on non-blocking
servers, such as Netty, Undertow, and Servlet containers. Individual chapters cover
the Spring WebFlux framework,
the reactive WebClient
, support for testing,
and reactive libraries. For Servlet-stack web applications,
see Web on Servlet Stack.
The Spring Frameworks lets you define an HTTP service as a Java interface with HTTP exchange methods. You can then generate a proxy that implements this interface and performs the exchanges. This helps to simplify HTTP remote access and provides additional flexibility for to choose an API style such as synchronous or reactive.
See REST Endpoints for details.
The spring-test
module provides mock implementations of ServerHttpRequest
,
ServerHttpResponse
, and ServerWebExchange
.
See Spring Web Reactive for a
discussion of mock objects.
WebTestClient
builds on these mock request and
response objects to provide support for testing WebFlux applications without an HTTP
server. You can use the WebTestClient
for end-to-end integration tests, too.
spring-webflux
depends on reactor-core
and uses it internally to compose asynchronous
logic and to provide Reactive Streams support. Generally, WebFlux APIs return Flux
or
Mono
(since those are used internally) and leniently accept any Reactive Streams
Publisher
implementation as input. The use of Flux
versus Mono
is important, because
it helps to express cardinality — for example, whether a single or multiple asynchronous
values are expected, and that can be essential for making decisions (for example, when
encoding or decoding HTTP messages).
For annotated controllers, WebFlux transparently adapts to the reactive library chosen by
the application. This is done with the help of the
{api-spring-framework}/core/ReactiveAdapterRegistry.html[ReactiveAdapterRegistry
], which
provides pluggable support for reactive library and other asynchronous types. The registry
has built-in support for RxJava 3, Kotlin coroutines and SmallRye Mutiny, but you can
register others, too.
For functional APIs (such as [webflux-fn], the WebClient
, and others), the general rules
for WebFlux APIs apply — Flux
and Mono
as return values and a Reactive Streams
Publisher
as input. When a Publisher
, whether custom or from another reactive library,
is provided, it can be treated only as 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, given a Publisher
that is not a Mono
, the Jackson JSON message writer
expects multiple values. If the media type implies an infinite stream (for example,
application/json+stream
), values are written and flushed individually. Otherwise,
values are buffered into a list and rendered as a JSON array.