Spring HTTP Interfaces should be in spring-webflux

Affects: 6.0

With the introduction of HTTP Interfaces for REST clients, it seems the lines between spring-web and spring-webflux are blurred.

My understanding of these two packages is one is the traditional Spring MVC while the other is reactive.

If I have a typical (Spring MVC) Spring Boot application, I have the option of using RestTemplate out of the box.

If I want to use a modern client, I can use WebClient, but I now require a dependency on spring-webflux. This is not an issue since WebClient is contained within spring-webflux.

Now I want to use HTTP Interfaces which is contained within spring-web, but it requires a dependency on spring-webflux since the underlying infrastructure (HttpClientAdapter for example) requires Project Reactor.

If HTTP Interfaces has a hard requirement on reactivity, it makes sense that the code be contained in spring-webflux

Note: I am intetntionally ignoring/leaving out other HTTP client libraries such as Spring Cloud OpenFeign, OkHttp, JDK HTTP Client, etc. This issue focuses solely on Spring provided HTTP clients.

Comment From: bclozel

spring-web contains the HTTP and Web infrastructure for both spring-webmvc and spring-webflux (home of the Spring Web frameworks). We've thoroughly discussed at the time whether WebClient should be in spring-webflux, in spring-web like RestTemplate or in some other module. In the end, we settled on this arrangement as this is the one that worked out the best with the design and the packages arrangement. I also think there's a misunderstanding about the HttpServiceProxyFactory and its link to WebClient.

So in summary: * spring-web is not only about MVC, but shared by both WebFlux and MVC * Flux and Mono are optionally supported in Spring MVC, so they're not only meant for the reactive stack * Flux and Mono are optionally supported in this feature as well; your contracts can be all blocking * the HttpServiceProxyFactory uses a client adapter - so it is technically decoupled from the adapter shipped in spring-webflux and we could provide other implementations. * WebClient provides async and streaming support out of the box (unlike RestTemplate) so I guess this is why we chose this as the main implementation

For those reasons, I don't think we should move those contracts to a different artifact. Thanks for reaching out!