Spring RestClient request factories: pin the transport you test

The classpath can change the transport

A client built without an explicit request factory may select a different implementation when HTTP libraries are added or removed. That can change connection-pool behavior, timeout support and error handling even when the call site stays the same. For a receipt-risk lookup, configure the transport deliberately and run the same library set in tests and the packaged artifact.

RestClient itself is reusable across threads. That does not make the upstream service fast, nor does it supply a safe retry policy. The timeout lesson treats the transport setting as part of a larger request deadline, and the retry lesson separates read calls from writes.

Keep response ownership visible

A synchronous request occupies a calling thread until it completes or fails. If a servlet handler calls the downstream service, enough simultaneous slow responses can exhaust its request workers. Bound the client call and the number of concurrent admissions; measure saturation with an actual slow local server, then with the real upstream failure mode.

RestClientBoundaryTest now runs an explicit SimpleClientHttpRequestFactory against a loopback HTTP server. The configuration below remains a design sketch; the checked test uses a concrete factory and a random local port. Do not extrapolate performance from reactive demand tests to this blocking client.

Working sketch

RestClient riskClient = RestClient.builder()
    .requestFactory(selectedRequestFactory)
    .baseUrl(riskServiceBaseUrl)
    .build();

Verification boundary

RestClientBoundaryTest.explicitFactoryReadsTheUpstreamResponse checks a selected SimpleClientHttpRequestFactory over loopback; the displayed generic factory variable is a design sketch.

Costs and limits

The selected factory, connection pool and timeout behavior require a packaged-artifact test with the chosen HTTP library.

Common Mistakes

• Do not assume the same classpath always selects the same transport.
• Do not call a blocking client non-blocking because the server also has WebFlux dependencies.
• Do not treat a reusable client as proof of bounded upstream latency.

Read next

Spring HTTP client timeouts: bound the call inside the request deadline, Spring HTTP retries: only replay a command with a defined identity, Spring reactive foundations: request values and cancel a subscription, Spring task executors: capacity, rejection and lost context.

Checked outbound HTTP continuation

Continue with Spring RestClient transport: run the factory you configured.