The RestClient provides a very convenient API on top of HTTP Clients implementations from OpenJDK, Apache, Jetty, and Netty. All those HTTP Clients provide support for performing asynchronous calls. However, the RestClient APIs do not support asynchronous behavior.
The current alternative is skipping Spring and using the underlying HTTP Client library directly or switching to reactive.
I would like to suggest extending the RestClient to support asynchronous calls, and I'm available to help out anyway I can.
Comment From: bclozel
Hello @ThomasVitale , thanks for reaching out. I have discussed this issue with @sdeleuze and he shared some additional context for this issue. This calls for a broader response so I'll start with that.
We have designed RestClient as a modern developer API, but still reusing the same infrastructure as RestTemplate for issuing requests, decoding content and intercepting exchanges. If we want to handle asynchronous calls properly, we would need a new base infrastructure that mirrors what our reactive HTTP layer does. This calls for a brand new HTTP client, the fourth one in Spring Framework...
HTTP client libraries do support asynchronous calls, but in different ways. For example, the JDK's HttpClient supports java.util.concurrent.Flow, Jetty uses callbacks or reactive streams, HttpComponents uses Future, etc. The Java platform team has been working on Virtual Threads and Structured Concurrency. If we were to consider another client, I think this would be an obvious path to explore. Unfortunately, it's too soon to consider this work stream in Spring Framework. While implementations are pretty solid at this stage, the Java ecosystem is far from being aligned there. Also, we know very little about the expectations of developers. Should we support backpressure and how? What's the expected user-facing API for scatter-gather, timeout, streaming scenarios? Should we consider deprecating one or more existing HTTP clients in our codebase as a result?
WebClient is pretty solid in that space and has been widely adopted. I understand that the reactive APIs are quite viral and that adopting them in libraries is not as easy as in applications. If you are working on a neutral library, maybe using JDK's HttpClient is the safest bet at this point.
We will reconsider this in the future but in the meantime I will close this issue as we have nothing actionable on this right now.
Comment From: tzolov
As I've been struggling with this issue in the SpringAI and MCP projects, I can second @ThomasVitale's suggestion.
RestClient's lack of async support makes it incompatible with Server-Sent Events (SSE), which is crucial as virtually all GenAI APIs use SSE for streaming responses. While I've implemented a custom HttpClient-based solution (FlowSseClient) for MCP, this workaround isn't suitable for Spring AI's broader needs.
Using WebClient with its heavy, coupled client/server dependencies and auto-configurations is an unfortunate design choice that significantly impacts the Spring AI architecture and user experience.
Comment From: bclozel
Thanks for the feedback @tzolov . Spring Framework structured this in order to avoid tangles and split packages and for many other reasons. I agree that the effect on auto-configurations is not ideal. The Spring Boot team is considering splitting auto-configurations and creating dedicated starters for clients.