In Spring WebClient is the only supported way to consume SSE streams. However, using WebClient introduce a reactive streams increasing application complexity.
Ideally RestClient can support the consumption of SSE streams allowing developers to keep codebases simple.
Spring offers reactive and non-reactive facilities for producing SSE events. Adding the ability to consume SSE streams in a reactive and non-reactive ways bring the server side and client side experience to parity.
Comment From: tzolov
I believe this is related: https://github.com/spring-projects/spring-framework/issues/34290
Comment From: rstoyanchev
Historically RestTemplate exposed low level streaming via InputStream and OutputStream. For WebClient, with Reactive Streams (error/completion/cancel/demand signals) and a functional, java.util.stream-like API, it was natural natural to provide higher level streaming. RestClient picks up from where RestTemplate was.
How to consume an SSE stream is a key question. Historically, an API of this kind is callback-based to avoid blocking. In the JDK, the HttpClient has HttpResponse.BodyHandler (essentially Reactive Streams Flow.Subscriber) including one that splits the response by line. We need the Loom friendly equivalent.
In modern Java with Loom, it's natural to use a pull-style API that blocks, and integrates well with Structured Concurrency for responsiveness to cancellation. A basic version with rendezvous hand-off is straight-forward enough, but a more advanced version that supports prefetching raises plenty of questions. An even more advanced, functional API, is even more ambitious.
There is currently nothing in the JDK for this, and it's not going to come soon (e.g. see Structured Concurrency JEP 505. We need to explore alternatives in the mean time.