Add builder support for SimpleClientHttpRequestFactory

[jminkkk]

I would like to propose adding a Builder pattern to SimpleClientHttpRequestFactory in order to support fluent and immutable configuration of commonly used properties such as connectTimeout, readTimeout, proxy, and chunkSize.

Current usage example (mutable setters):

SimpleClientHttpRequestFactory factory = new SimpleClientHttpRequestFactory();
factory.setConnectTimeout(3000);
factory.setReadTimeout(5000);
factory.setProxy(Proxy.NO_PROXY);
factory.setChunkSize(2048);

Proposed usage example (fluent builder):

SimpleClientHttpRequestFactory factory = SimpleClientHttpRequestFactory.builder()
    .connectTimeout(3000)
    .readTimeout(5000)
    .proxy(Proxy.NO_PROXY)
    .chunkSize(2048)
    .build();

Motivation

The current mutable setter approach requires multiple separate calls and can lead to partially configured instances. A builder pattern enables fluent, thread-safe, and immutable configuration, improving readability and reducing errors. This approach is consistent with the design trends observed in several modern Spring APIs that have adopted or are adopting the builder pattern, helping to provide a more fluent and robust developer experience.

Proposal

Add a static nested Builder class with chainable setters and a build() method returning an immutable, fully configured SimpleClientHttpRequestFactory.

[rstoyanchev]

There are many ClientHttpRequestFactory implementations, and I don't think we should decide on whether to add builders one at at time.

Generally, these factories are infrastructure components that are configured from a single place, so having a builder doesn't make a big difference, and I don't think we should be adding them across all factories.

SimpleClientHttpRequestFactory is not a mainstream choice. For most cases you need to upgrade to one of the other HTTP client library choices, and nowadays there is also a replacement in the JDK with java.net.http.HttpClient.

Spring Boot provides infrastructure and abstractions for configuring request factories that supersedes direct use of the request factories.

For all these reasons, I don't think we will process this, but thanks for the suggestion in any case.