Loading published curriculum…

12 · Spring Boot and the web request lifecycle / LESSON 58 OF 102

Outbound HTTP, timeouts, and failure handling

A remote API call adds latency and failure modes that your service cannot control.

Before this lesson: Bounded pagination and consistent error responses

Understand the topic

Configure connection and response/read timeouts on the underlying HTTP client. A retry is safe only when operation semantics permit repetition or the server supports a proper idempotency mechanism. Never hold a database transaction open while waiting on an avoidable remote call.

Use RestClient for synchronous HTTP with an explicitly configured request factory. Validate remote response shape and distinguish network failure, timeout, and remote 4xx/5xx. Test with a local stub instead of depending on a public service during every build.

EXAMPLE · JAVA

RestClient configuration fragment

var factory = new org.springframework.http.client.SimpleClientHttpRequestFactory();
factory.setConnectTimeout(java.time.Duration.ofSeconds(2));
factory.setReadTimeout(java.time.Duration.ofSeconds(3));
var client = org.springframework.web.client.RestClient.builder()
 .baseUrl("http://localhost:9090")
 .requestFactory(factory).build();
String body = client.get().uri("/status").retrieve().body(String.class);

What to expect

Against a local stub, reads /status with bounded connection and read waits. These are component timeouts, not a universal end-to-end deadline.

YOUR TURN

Put it into practice

  1. 01Create a local stub that returns success, 500, and delayed responses.
  2. 02Define which failures can be retried and cap attempts and total elapsed time.
  3. 03Verify: A stalled dependency cannot hold the request forever and writes are not duplicated by blind retries.

Pass a quiz or complete a lab to check today’s streak. Each lesson counts once per day, including when you review it later.

UNDER THE HOOD

Build the mental model

A remote API call adds latency and failure modes that your service cannot control.

  1. 01Configure connection and response/read timeouts on the underlying HTTP client. A retry is safe only when operation semantics permit repetition or the server supports a proper idempotency mechanism. Never hold a database transaction open while waiting on an avoidable remote call.
  2. 02Use RestClient for synchronous HTTP with an explicitly configured request factory. Validate remote response shape and distinguish network failure, timeout, and remote 4xx/5xx. Test with a local stub instead of depending on a public service during every build.
  3. 03Trace the example: Against a local stub, reads /status with bounded connection and read waits. These are component timeouts, not a universal end-to-end deadline.

A mistake worth avoiding

A downstream outage exhausts application request capacity.

DEBUGGING ROOM

Something broke. Where do you look?

A downstream outage exhausts application request capacity.

Before revealing the diagnosis, write down your first investigation step.

CHECK YOUR UNDERSTANDING

Is every failed POST safe to retry automatically?

Choose one answer

BUILD IT YOURSELF

Create a local stub that returns success, 500, and delayed responses.

  1. 1.Create a local stub that returns success, 500, and delayed responses.
  2. 2.Define which failures can be retried and cap attempts and total elapsed time.
  3. 3.Reproduce this failure, then repair it: A downstream outage exhausts application request capacity.

Acceptance checklist

Lab completion is your self-report. Knowledge checks do not certify project quality.

RETRIEVE IT FROM MEMORY

Is every failed POST safe to retry automatically?

Revisit this lesson in three days after a successful check or lab.

Ready for the next step?

A stalled dependency cannot hold the request forever and writes are not duplicated by blind retries.

Reading is separate from passing a knowledge check or completing a lab.

Go deeper · official references