WebClient vs RestTemplate: Choosing an External API Client

Background

For the Kakao Tech Campus final project, I needed to integrate with the Everytime API. I needed a stable, flexible HTTP client.

In the Spring ecosystem, there are two main options:

• RestTemplate
• WebClient

---

The Problem with RestTemplate

The Spring docs say:

As of 5.0, the non-blocking, reactive WebClient offers a modern alternative to the RestTemplate with efficient support for both sync and async, as well as streaming scenarios. The RestTemplate will be deprecated in a future version and will not have major new features added going forward.

In short:

• No new features for RestTemplate
• Scheduled for deprecation
• WebClient is the officially recommended client

---

Choosing WebClient

I had no plans to go full WebFlux—I just needed efficient external API calls.

Decision:

• Keep the overall service on Spring MVC
• Use WebClient for all external API calls

This way, if I ever need async processing or reactive extensions later, WebClient will be ready.

---

Trade-off

Pros:

• Adopted the officially recommended client
• Flexible config for connection pools, timeouts, retries
• Easy to extend to async/reactive later

Cons:

• Requires adding spring-webflux module, pulling in WebFlux dependencies
• Most calls end up using block(), so non-blocking benefits aren’t fully realized
• Team needs to learn WebClient’s reactive API

Risks:

• Overusing block() may limit performance gains
• WebFlux dependencies might cause unexpected conflicts in some runtimes

---

Lessons Learned

• Tech choices involve trade-offs. RestTemplate is more familiar, but WebClient is the right choice long-term.
• You don’t need to go full reactive to use WebClient—just use block() for sync.
• Document decisions like this in an ADR. You’ll thank yourself later when someone asks “why?”

---

From Kakao Tech Campus 3rd cohort final project, while integrating with Everytime.