spring-webflux depende de reactor-core y lo usa internamente para formular lógica
asincrónica y brindar soporte para Reactive Streams. Normalmente, las API de WebFlux devuelven Flux o
Mono (ya que se usan internamente) y esperan cualquier implementación de Publisher de la
especificación Reactive. El uso de Flux versus Mono es importante porque ayuda a expresar
el poder de un conjunto; por ejemplo, si se esperan uno o más valores asincrónicos, lo cual puede ser importante,
para la toma de decisiones (por ejemplo, al codificar o decodificar mensajes HTTP).
Con controladores anotados, WebFlux se adapta fácilmente a la biblioteca reactiva elegida por la aplicación. Esto se
hace usando ReactiveAdapterRegistry, que proporciona soporte conectable para la
biblioteca reactiva y otros tipos asincrónicos. El registro tiene soporte integrado para las corrutinas RxJava 3,
Kotlin y SmallRye Mutiny, pero puede registrar otros adaptadores de terceros.
A partir de Spring Framework 5.3.11, la compatibilidad con RxJava 1 y 2 se suspendió de acuerdo con las pautas de fin de vida útil de RxJava y las pautas de actualización a RxJava 3.
Para las API funcionales (como puntos finales funcionales, WebClient y otras), se aplican las reglas
comunes a las API de WebFlux: Flux y Mono. se utilizan como valores de retorno y Publisher
de la especificación Reactive Streams como entrada. Cuando se proporciona un Publisher, ya sea uno
personalizado o de otra biblioteca reactiva, solo se puede tomar como una secuencia con semántica desconocida
(0..N). Sin embargo, si conoce la semántica, puede envolverla con Flux o
Mono.from(Publisher) en lugar de pasar el Publisher sin formato.
Por ejemplo, si tiene un Publisher que no es Mono, el escritor de mensajes Jackson JSON
acepta múltiples valores. Si el tipo de medio es una secuencia infinita (por ejemplo,
application/json+stream), los valores se escriben y se restablecen individualmente. De lo contrario,
los valores se almacenan en una lista y se generan como una matriz en formato JSON.