Perhaps we could make the requestFactory(Class<? extends ClientHttpRequestFactory> requestFactory) method behave as factory detection does?

I think what you're describing here is the expected behavior, since:

• RestTemplateBuilder instances are immutable (calling a method on it returns a new instance)
• RestTemplate and ClientHttpRequestFactory don't support a per-request configuration model
• The ClientHttpRequestFactory is here to instantiate requests with the given configuration and holds the shared resources (such as connection pools)

In most cases, sharing a ClientHttpRequestFactory between RestTemplate instances is a good idea to optimize resource usage. If you wish to have different configuration timeouts for RestTemplate, then separate ClientHttpRequestFactory instances is the way to go - resource usage will be the price to pay. Again, RestTemplate doesn't support a per-request configuration model.

One could also argue the following: mutating the request factory options at runtime is supposed to change the request behaviour as well.

I don't think Spring Boot can change anything in this model. If we were to replicate the factory detection for that (by cloning/creating request factory instances for each builder call), we'd be breaking the expected behaviour for many: resources wouldn't be shared anymore between RestTemplate that share the same request factory instance.

I agree that the ClientHttpRequestFactory cannot be cloned for every new RestTemplateBuilderInstance (since ClientHttpRequestFactory could be a Spring bean and cloning a singleton bean isn't a good idea).

On the other hand, the two set...Timeout() methods (in contrast to all other RestTemplateBuilder properties) leads to a direct manipulation of the singleton ClientHttpRequestFactory, and this is not easy to solve...

One could also argue the following: mutating the request factory options at runtime is supposed to change the request behaviour as well.

It may be not very obvious to the user of RestTemplateBuilder to determine, which setter method mutates the request factory. We in fact were surprised by this behavior...

I would at least suppose to add a warning to the javadoc of setConnectionTimeout() and setReadTimeout(), like

 * WARNING:
 * Invocations of this method may change the timeout behavior of 
 * all allready build RestTemplates!!
 *

However, our concrete problem isn't solved this way ;-). We (lvm-it) like the RestTemplateBuilder pattern and use it to define a default RestTemplate configuration for all our teams (implemented as autoconfiguration, for instance setting some ClientHttpRequestInterceptors and a SSLContext for client-side certificates). But the problematic side-effects of timeouts prevents us from using RestTemplateBuilder at the moment ...

I changed my mind a bit and I think @wilkinsona is right.

Look at the following example; the RestTemplateBuilder behaviour is not consistent depending on the use case:

// auto-detect the client factory
RestTemplateBuilder builder = this.builder;
RestTemplate t1 = builder.setConnectTimeout(2_000).build();
RestTemplate t2 = builder.setConnectTimeout(1_000).build();
// separate connection factories, so each connection timeout is configured as expected
assertThat(t1.getRequestFactory()).isNotEqualTo(t2.getRequestFactory());

// Choose the client factory class
RestTemplateBuilder selectFactoryBuilder = this.builder.requestFactory(OkHttp3ClientHttpRequestFactory.class);
RestTemplate t3 = selectFactoryBuilder.setConnectTimeout(1_000).build();
RestTemplate t4 = selectFactoryBuilder.setConnectTimeout(2_000).build();
// Factory instance is shared, this test fails currently
assertThat(t3.getRequestFactory()).isNotEqualTo(t4.getRequestFactory());

// directly provide a client factory instance
ClientHttpRequestFactory factory = new SimpleClientHttpRequestFactory();
RestTemplateBuilder customFactoryBuilder = this.builder.requestFactory(factory);
RestTemplate t5 = customFactoryBuilder.setConnectTimeout(1_000).build();
RestTemplate t6 = customFactoryBuilder.setConnectTimeout(2_000).build();
// Factory instance is shared, connection timeout will be 2000 for both!
assertThat(t5.getRequestFactory()).isEqualTo(t6.getRequestFactory());

I agree that providing your own factory instance and changing the connection timeout down the line is a bit strange. But I think that, in general, the setConnectTimeout and setReadTimeout are the problematic ones. They break the "stateless" API contract.

After discussing that with the team (and given my previous comment), we've found that the inconsistency comes from the requestFactory(ClientHttpRequestFactory) method. We should indeed be consistent here and create an instance of that for each build() call.

Here's what we should do:

1. Deprecate requestFactory(ClientHttpRequestFactory requestFactory) in 1.5.x
2. Remove requestFactory(ClientHttpRequestFactory requestFactory) in 2.0.0
3. Add requestFactory(Supplier<ClientHttpRequestFactory> supplier) in 2.0.0
4. Make requestFactory(Class<? extends ClientHttpRequestFactory> requestFactory) consistent with the rest and only create the instance on the build() call.

After some thoughts, you should indeed share and reuse RestTemplate instances in your application, but the main goal of RestTemplateBuilder is for Spring Boot to provide some sensible defaults for creating such clients and avoid creating those as beans. Client customizers declared as beans are automatically detected and applied. We shouldn't add to much levels of indirection there. If you need something more specific,

We might have trouble deprecating requestFactory(ClientHttpRequestFactory requestFactory) in 1.5.x since we can't add the Supplier<ClientHttpRequestFactory> version there. I guess we could add a ClientHttpRequestFactoryFactory interface.... but... yuk :)

I'm tempted to leave 1.5 as it is, perhaps with some Javadoc warning that the instance is shared.