Is RestTemplate deprecated? How does it compare to RestClient and WebClient, and what should new code use?
answer
- maintenance mode, NOT deprecated (since Spring 5.0)
- new sync -> RestClient (6.1 / Boot 3.2)
- reactive -> WebClient (WebFlux)
- RestClient reuses factory/converters/interceptors
- RestClient.create(restTemplate) for migration
basics
~20 sRestTemplate is not deprecated but is in maintenance mode (bugfixes only) since Spring 5. For new synchronous code prefer RestClient (Spring 6.1+), which has a modern fluent API on the same infrastructure. Use WebClient for reactive/non-blocking code.
solid answer
~40 sRestTemplate is officially in maintenance mode since Spring Framework 5.0 — still fully supported and not deprecated, but no new features. The guidance for new synchronous code is RestClient, introduced in Spring 6.1 (Boot 3.2), a fluent, immutable client built on the same request factories, message converters, and interceptors as RestTemplate, so it reuses your existing config and thinking. WebClient is the reactive, non-blocking client from Spring WebFlux; it also works synchronously via block() but pulls in the reactive stack, so it's overkill purely for blocking calls. So: legacy/existing code → keep RestTemplate consistently; new blocking code → RestClient; reactive pipelines or streaming → WebClient. RestClient can even be created from an existing RestTemplate's configuration (RestClient.create(restTemplate)), which eases incremental migration.
code
java · 13 lines// Legacy synchronous (maintenance mode)
User a = restTemplate.getForObject("/users/{id}", User.class, id);
// Preferred new synchronous: RestClient (Spring 6.1+)
User b = restClient.get()
.uri("/users/{id}", id)
.retrieve()
.onStatus(HttpStatusCode::is4xxClientError,
(req, resp) -> { throw new UserNotFound(id); })
.body(User.class);
// Incremental migration: build RestClient from existing RestTemplate config
RestClient migrated = RestClient.create(restTemplate);go deeper
Know RestTemplate is old-but-supported and RestClient is the newer preferred synchronous client.
Distinguish maintenance-mode from deprecated and know WebClient is the reactive option.
Articulate the three-client decision matrix and that RestClient shares RestTemplate's infrastructure.
Own the org-wide client standard and an incremental, low-risk migration path (RestClient.create(restTemplate)), avoiding churn on stable code.
## "Deprecated" vs "maintenance mode" A common trap: RestTemplate is **not** deprecated. Its Javadoc and the reference docs say it is in **maintenance mode** — Spring will fix bugs and security issues but won't add major features. It remains a first-class, supported client used in enormous amounts of existing code, so you must be fluent in it. Saying "it's deprecated, never use it" is inaccurate. ## The three clients | Client | Style | Since | Notes | |---|---|---|---| | `RestTemplate` | synchronous, template-method | Spring 3 | Maintenance mode since 5.0 | | `RestClient` | synchronous, **fluent** | Spring 6.1 / Boot 3.2 | Modern replacement for RestTemplate | | `WebClient` | **reactive**, non-blocking (also blockable) | Spring 5 (WebFlux) | Needs the reactive stack | ### RestClient `RestClient` (package `org.springframework.web.client`) offers a fluent chain instead of many overloaded methods: ```java User u = restClient.get() .uri("/users/{id}", id) .retrieve() .body(User.class); ``` Critically it is built on the **same infrastructure** — `ClientHttpRequestFactory`, `HttpMessageConverter`s, `ClientHttpRequestInterceptor`s — as RestTemplate. So converters and interceptors you already know carry over, and you can create one from an existing template: `RestClient.create(restTemplate)`. It adds ergonomic error handling (`onStatus(...)`), `ResponseEntity` access via `.toEntity(...)`, and `ParameterizedTypeReference` support inline. ### WebClient `WebClient` from **spring-webflux** is fully reactive: it returns `Mono`/`Flux` and never blocks the calling thread, ideal for high-concurrency, streaming, or when you're already reactive. It *can* run synchronously with `.block()`, and before RestClient existed that was the recommended "modern" choice even for blocking code — but doing so drags in Reactor/WebFlux just to block, which is why **RestClient** is now preferred for plain synchronous use. ## Decision guide - **Existing RestTemplate code** → keep it; don't rewrite for its own sake. Be consistent within a codebase. - **New synchronous HTTP** → `RestClient`. - **Reactive app / streaming / very high concurrency** → `WebClient`. - **Migrating** → introduce `RestClient` alongside, optionally seeded from the existing RestTemplate config, and move call sites incrementally. ## Why the shift RestTemplate's API grew dozens of overloaded methods (`getForObject`, `getForEntity`, `postForObject`, `exchange`…) that are hard to discover and awkward for headers/generics. RestClient's fluent builder is more readable, immutable/thread-safe, and unifies the sync ergonomics with WebClient's style — while keeping the well-understood blocking, converter-based model underneath. ## Interview framing Strong answer: "Not deprecated, but maintenance mode. I use RestClient for new synchronous work because it reuses the same converters/interceptors with a cleaner fluent API; WebClient only when I'm reactive. I keep legacy RestTemplate consistent rather than churn it."
- If RestClient and WebClient both exist, why not always use WebClient?WebClient is reactive and pulls in the WebFlux/Reactor stack. For purely blocking calls that's unnecessary weight; RestClient gives the modern fluent API on the plain synchronous stack. Use WebClient when you're actually reactive.
- Does moving to RestClient mean rewriting your message converters and interceptors?No. RestClient uses the same ClientHttpRequestFactory, HttpMessageConverters, and ClientHttpRequestInterceptors, so existing config carries over — you can even seed a RestClient from an existing RestTemplate.
saying these in an interview costs you the question
- Saying RestTemplate is deprecated (it's maintenance mode, not deprecated)
- Claiming RestTemplate will be removed in the next Spring release
- Saying WebClient is the only modern option (ignoring RestClient)
- Thinking migrating to RestClient forces rewriting converters/interceptors