RSocket Interaction Models & RSocketRequester

RSocket is a binary, message-driven application protocol built on Reactive Streams semantics (backpressure included). Unlike HTTP's single request/response shape, it defines **four interaction models**, and Spring Messaging exposes all four through annotations and the `RSocketRequester` fluent client. **The four models** 1. **Request-Response** — the client sends one payload and receives exactly one payload back. This is the HTTP-like case. Spring handler returns `Mono<T>`; the client calls `retrieveMono(...)`. 2. **Fire-and-Forget** — the client sends one payload and the server sends *no* response at all (not even an acknowledgement of completion at the app level). Useful for high-volume, lossy-tolerant signals (metrics, logs). Spring handler returns `Mono<Void>` or `void`; the client calls `send()` (which itself returns a `Mono<Void>` that completes when the frame is written, not when processed). 3. **Request-Stream** — the client sends one payload and receives a stream of zero-to-many payloads back, with backpressure. Spring handler returns `Flux<T>`; the client calls `retrieveFlux(...)`. 4. **Request-Channel** — a fully bidirectional stream: both sides send a stream of payloads. Spring handler declares a `Flux<T>` (or `Publisher<T>`) **parameter** and returns a `Flux<T>`; the client passes a `Flux` to `.data(...)` and calls `retrieveFlux(...)`. **How Spring picks the model.** With `@MessageMapping`, you never name the interaction model explicitly. Spring's `RSocketMessageHandler` infers it from the method signature: - Return `Flux` ⇒ streaming response; return `Mono`/plain value ⇒ single response; return `Mono<Void>`/`void` ⇒ no response (fire-and-forget). - A streaming **parameter** (`Flux`) ⇒ request-channel. **The client side — `RSocketRequester`.** It is a thin, fluent, reactive client: ``` requester.route("prices.{symbol}", "AAPL") // route metadata .data(request) // payload (may be a Publisher) .retrieveFlux(Quote.class); // chooses interaction model ``` The *terminal* method chooses the model: `retrieveMono` (request-response), `retrieveFlux` (request-stream, or request-channel when `data(...)` was given a `Flux`), and `send()` (fire-and-forget). If you never subscribe to the returned publisher, **nothing is sent** — these are cold, lazy publishers. **Route metadata.** RSocket has no URLs; routing is carried in frame *metadata*. Spring encodes the route via composite metadata using the well-known mime type `message/x.rsocket.routing.v0` (`WellKnownMimeType.MESSAGE_RSOCKET_ROUTING`). `route("a.b.{id}", var)` expands template variables and attaches this metadata; the responder matches it against `@MessageMapping("a.b.{id}")` patterns (Ant-style, with `{}` variables bound via `@DestinationVariable`). **Edge cases & gotchas.** - Fire-and-forget's `send()` completing does **not** mean the server processed (or even received) the message — there is no application-level reply. - Mismatching models breaks silently-ish: calling `retrieveMono` against a handler that streams gives you only the first element; calling `retrieveFlux` on a request-response route yields a single-element flux. - Request-stream and request-channel honor Reactive Streams backpressure over the wire via RSocket REQUEST_N frames — a slow consumer throttles the producer. - `@ConnectMapping` is a *fifth*, connection-level hook (not an interaction model): it handles the setup payload/metadata at connect time and must return `void`/`Mono<Void>` — it cannot reply with data. **When to use which.** Request-response for RPC-style calls; fire-and-forget for cheap one-way signals; request-stream for server push / subscriptions; request-channel for interactive, long-lived bidirectional exchanges (e.g., live collaboration, flow-controlled uploads).