Documented Rest client customization promotes bad practice with ClientHttpRequestFactoryBuilder.detect()

[michaldo]

Spring Boot 4.0.6
https://docs.spring.io/spring-boot/reference/io/rest-client.html#io.rest-client.restclient

@Service
public class MyService {

	private final RestClient restClient;

	public MyService(RestClient.Builder restClientBuilder, SslBundles sslBundles) {
		HttpClientSettings settings = HttpClientSettings.ofSslBundle(sslBundles.getBundle("mybundle"))
			.withReadTimeout(Duration.ofMinutes(2));
		ClientHttpRequestFactory requestFactory = ClientHttpRequestFactoryBuilder.detect().build(settings);
		this.restClient = restClientBuilder.baseUrl("https://example.org").requestFactory(requestFactory).build();
	}

	public Details someRestCall(String name) {
		return this.restClient.get().uri("/{name}/details", name).retrieve().body(Details.class);
	}

}

If application has MyService1, MyService2, MyService3, MyService4, MyService5, each will have own http client, with isolated resources - threads and connections.
I think, by default the application should strive to reuse resources and documentation should reflect it.
I understood it is not trivial with existing API and implementation variants - for example two Rest clients with different connect timeouts can reuse single Apache http client but not single Java SDK http client.

Regardless its not trivial, documentation should be fair andat least warn that code
ClientHttpRequestFactoryBuilder.detect().build(settings);

is something developer 99% does not want in application @Service.

(And 100% of cloud providers love :))

[jiteshkhatri11]

This seems like an important documentation concern, especially for developers who may copy the example directly into multiple @Service classes.

Creating request factories through ClientHttpRequestFactoryBuilder.detect().build(settings) inside service constructors can unintentionally lead to isolated HTTP client resources (connection pools, threads, TLS state) instead of shared infrastructure managed at the application level.

Even if the API intentionally allows this flexibility, adding a note about resource reuse and recommended bean-scoped/shared client configuration patterns could help prevent inefficient production setups.