Spring Boot 4 HTTP Service Clients: @HttpExchange Interfaces with RestClient (Complete Guide)

Versions. Everything ran on Spring Boot 4.1.2, Spring Framework 7.0.10, Spring Security 7.1.2 and JDK 25.0.5 (Temurin, LTS). Those are the latest GA releases in maven-metadata.xml on 6 November 2026; 4.2.0-RC2 exists but is a release candidate, not GA. Boot 4.0.0 reached Maven Central on 20 November 2025 and 4.1.0 on 10 June 2026. The first version of this post was tested on Boot 4.0.5, Framework 7.0.2 and Java 21.0.3. The whole module is here: http-service-clients.

Corrections to the first version of this post. (1) The group properties are spring.http.serviceclient.<group>.* with global defaults under spring.http.clients.*; the keys the old post showed (spring.http.client.service.group.*) are silently ignored. (2) A missing base URL does not cause a NullPointerException; it fails with IllegalArgumentException: URI with undefined scheme. (3) @RestClientTest lives in org.springframework.boot.restclient.test.autoconfigure, and @RestClientTest(PostService.class) does not make the interface a bean. (4) Optional<Post> does not turn a 404 into an empty result by default. (5) A wrong return type surfaces as RestClientException wrapping Jackson 3’s tools.jackson...MismatchedInputException. (6) @ClientRegistrationId only does anything once you register an OAuth2RestClientHttpServiceGroupConfigurer; Boot does not. (7) Spring Cloud load-balancing and circuit-breaker group configurers exist, but I only confirmed the classes, not that they apply “automatically”. Details and evidence are in the sections below.

What a Spring Boot HTTP Service Client actually is

What you need: the right starter and a Java 17+ baseline

  <parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>4.1.2</version>
    <relativePath/>
  </parent>

      <artifactId>spring-boot-starter-restclient</artifactId>
    </dependency>

Start here: the data model you are mapping

package com.ankurm.hsc.model;

public record Post(Integer id, Integer userId, String title, String body) {
}

The interface that does all the work

@HttpExchange("/posts")
public interface PostClient {

    @GetExchange
    List<Post> findAll();

    @GetExchange
    List<Post> findByUser(@RequestParam Integer userId);

    @GetExchange("/{id}")
    Post findById(@PathVariable Integer id);

    @GetExchange("/{id}")
    ResponseEntity<Post> findEntity(@PathVariable Integer id);

    /** Used only to show that Optional does NOT turn a 404 into Optional.empty(). */
    @GetExchange("/{id}")
    Optional<Post> findOptional(@PathVariable Integer id);

    @PostExchange
    Post create(@RequestBody Post post);

    @PutExchange("/{id}")
    Post update(@PathVariable Integer id, @RequestBody Post post);

    @DeleteExchange("/{id}")
    void delete(@PathVariable Integer id);
}

How the interface works

Registering the interface: one annotation, no factory boilerplate

@Configuration(proxyBeanMethods = false)
@EnableResilientMethods
@ImportHttpServices(group = "posts", types = {PostClient.class, ParamsClient.class})
@ImportHttpServices(group = "github", types = GitHubClient.class)
@ImportHttpServices(group = "flaky", types = FlakyClient.class)
@ImportHttpServices(group = "resilient", types = ResilientClient.class)
@ImportHttpServices(group = "bearer", types = SecureClient.class)
@ImportHttpServices(group = "apikey", types = ApiKeyClient.class)
@ImportHttpServices(group = "oauth", types = OAuthClient.class)
public class HttpClientsConfig {

# groups the HttpServiceProxyRegistry knows about
group apikey  -> [ApiKeyClient]
group bearer  -> [SecureClient]
group flaky   -> [FlakyClient]
group github  -> [GitHubClient]
group oauth   -> [OAuthClient]
group posts   -> [ParamsClient, PostClient]
group resilient -> [ResilientClient]
PostClient bean is a JDK proxy: true
registry.getClient("posts", PostClient.class) is the injected bean: true

@ImportHttpServices(
    group = "jsonplaceholder",
    basePackages = "com.example.demo.client"
)
@Configuration(proxyBeanMethods = false)
public class HttpClientConfig {
}

Base URL, timeouts and per-group config — all in application.yml

spring:
  http:
    clients:                       # defaults for every group
      connect-timeout: 2s
      read-timeout: 5s
    serviceclient:                 # one entry per group registered with @ImportHttpServices
      posts:
        base-url: ${stub.url}
        default-header:
          X-Client: hsc-demo
      github:                      # a second API with its own base URL; never called in the tests
        base-url: https://api.github.com
        read-timeout: 5s
      flaky:
        base-url: ${stub.url}
        read-timeout: 1500ms       # per-group override of spring.http.clients.read-timeout
      resilient:
        base-url: ${stub.url}
      bearer:
        base-url: ${stub.url}
      apikey:
        base-url: ${stub.url}
        default-header:
          X-Api-Key: demo-key-123
      oauth:
        base-url: ${stub.url}

The keys in the first version of this post were wrong, and Boot said nothing. It showed spring.http.client.service.group.jsonplaceholder.base-url and spring.http.client.service.connect-timeout. Boot 4.1.2 binds spring.http.serviceclient.<group>.base-url (a Map of HttpClientProperties, with base-url, default-header, timeouts) and global defaults under spring.http.clients.*. With the old keys the application starts fine and the first call fails. Real run:

# A. the keys the article's first version used (spring.http.client.service.group.<g>.base-url)
findAll() -> java.lang.IllegalArgumentException: URI with undefined scheme

# B. the keys Spring Boot 4.1.2 binds (spring.http.serviceclient.<g>.base-url)
findAll() -> OK -> 3

# C. no base URL at all
findAll() -> java.lang.IllegalArgumentException: URI with undefined scheme

# Base URL for the "jsonplaceholder" group
spring.http.client.service.group.jsonplaceholder.base-url=https://jsonplaceholder.typicode.com

# Global timeout (applies to all groups)
spring.http.client.service.connect-timeout=5s
spring.http.client.service.read-timeout=10s

# Per-group timeout override
spring.http.client.service.group.jsonplaceholder.read-timeout=3s

# JSONPlaceholder group
spring.http.client.service.group.jsonplaceholder.base-url=https://jsonplaceholder.typicode.com

# GitHub group
spring.http.client.service.group.github.base-url=https://api.github.com
spring.http.client.service.group.github.read-timeout=5s

Injecting and using the client — it is just a bean

# CRUD against the stub (every call is a real HTTP request)
findAll() -> 3 posts
findById(1) -> Post[id=1, userId=1, title=First post, body=Body of the first post]
findByUser(2) -> [3]
findEntity(2) -> status 200 OK, Content-Type application/json
create(...) -> id 101
update(1, ...) -> title 'Updated Title'
delete(1) -> void, no exception

@Bean
    ApplicationRunner runner(PostClient postService) {
        return args -> {

            // GET all posts
            List<Post> allPosts = postService.findAll();
            System.out.println("Total posts: " + allPosts.size());

            // GET a single post
            Post post = postService.findById(1);
            System.out.println("Post 1 title: " + post.title());

            // POST a new post
            Post newPost = new Post(null, 1, "HTTP Service Clients", "Spring Boot 4 is amazing!");
            Post created = postService.create(newPost);
            System.out.println("Created post ID: " + created.id());

            // PUT update
            Post updated = postService.update(1, new Post(1, 1, "Updated Title", "Updated body"));
            System.out.println("Updated title: " + updated.title());

            // DELETE
            postService.delete(1);
            System.out.println("Deleted post 1");
        };
    }

Consuming multiple APIs with service groups

@HttpExchange
public interface GitHubClient {

    record Repository(Long id, String name, String full_name, String description) {
    }

    record Milestone(int number, String title, String state) {
    }

    @GetExchange("/users/{username}/repos")
    List<Repository> getRepositories(@PathVariable String username);

    @GetExchange("/repos/{owner}/{repo}/milestones")
    List<Milestone> getMilestones(@PathVariable String owner, @PathVariable String repo);
}

Supported method parameters and return types

@HttpExchange
public interface ParamsClient {

    @GetExchange("/echo/headers")
    Map<String, String> withHeader(@RequestHeader("X-Correlation-Id") String correlationId);

    @GetExchange("/posts")
    List<Post> optionalParam(@RequestParam(required = false) Integer userId);

    @GetExchange("/posts")
    List<Post> defaultedParam(@RequestParam(defaultValue = "2") Integer userId);

    /** A java.net.URI argument replaces the whole URL, base URL included. */
    @GetExchange
    Post byUri(URI uri);
}

# argument kinds (ParamsClient)
@RequestHeader        -> upstream saw X-Correlation-Id=abc-123
@RequestParam(required=false), null -> 3 posts
@RequestParam(defaultValue="2")   -> posts [3]
URI argument          -> Second post

Return types

Programmatic configuration with RestClientHttpServiceGroupConfigurer

    RestClientHttpServiceGroupConfigurer githubDefaults() {
        return groups -> groups.filterByName("github").forEachClient((group, builder) -> builder
                .defaultHeader("Accept", "application/vnd.github.v3+json")
                .defaultHeader("X-GitHub-Api-Version", "2022-11-28")
                .requestInterceptor((HttpRequest request, byte[] body, ClientHttpRequestExecution execution) -> {
                    System.out.println("Calling: " + request.getURI());
                    return execution.execute(request, body);
                }));

When the upstream misbehaves: error handling

# 1. framework defaults (a plain RestClient, no status handler)
findById(99) -> HttpClientErrorException$NotFound
  status      : 404 NOT_FOUND
  message     : 404 Not Found: "{"type":"https://stub.example/problems/post-not-found","title":"Post not found","status":404,"detail":"No post with id 99","instance":"/posts/99"}"
  content-type: application/problem+json
  getResponseBodyAs(ProblemDetail): title='Post not found' detail='No post with id 99' type=https://stub.example/problems/post-not-found
alwaysDown() -> HttpServerErrorException.ServiceUnavailable, status 503 SERVICE_UNAVAILABLE

# 2. a response that never comes: read timeout is 1500ms on the flaky group, /slow takes 3000ms
slow() -> ResourceAccessException, cause java.net.http.HttpTimeoutException
  message: I/O error on GET request for "http://127.0.0.1:<port>/slow": Request cancelled

# 3. nobody listening
findAll() -> ResourceAccessException, cause java.net.ConnectException

defaultStatusHandler: your own exceptions, once per group

    public void handle(HttpRequest request, ClientHttpResponse response) throws IOException {
        int status = response.getStatusCode().value();
        ProblemDetail problem = readProblem(response, status);
        if (status == 404) {
            throw new UpstreamNotFoundException(problem);
        }
        if (status == 422) {
            throw new UpstreamValidationException(problem);
        }
        if (response.getStatusCode().is5xxServerError()) {
            throw new UpstreamUnavailableException(status, problem.getDetail());
        }
        // anything else (401, 403, 409 ...): fall back to a generic failure carrying the body
        throw new IllegalStateException("Unexpected upstream status " + status + ": " + problem.getDetail());
    }

    RestClientHttpServiceGroupConfigurer postsErrorHandling() {
        return groups -> groups.filterByName("posts").forEachClient((group, builder) ->
                builder.defaultStatusHandler(
                        status -> status.isError(), new UpstreamProblemStatusHandler()));

# 6. our own defaultStatusHandler on the "posts" group (UpstreamProblemStatusHandler)
findById(99) -> UpstreamNotFoundException: Upstream says not found: No post with id 99
  problem.type=https://stub.example/problems/post-not-found instance=/posts/99
create(blank title) -> UpstreamValidationException: Upstream rejected the request: Validation failed
  extension 'errors' = [{field=title, message=must not be blank}]
alwaysDown() -> UpstreamUnavailableException: Upstream unavailable (503): Upstream is down for maintenance

# 4. Optional<Post> and ResponseEntity<Post> on a 404 with the default handler
findOptional(99) -> NotFound
findEntity(99)   -> NotFound

# 5. NotFoundRestClientAdapterDecorator (spring-web 7.0.10) turns a 404 into an empty result
findById(99)     -> null
findOptional(99) -> Optional.empty
findEntity(99)   -> status 404 NOT_FOUND, body null

Translating upstream errors for your own callers

@RestControllerAdvice
public class UpstreamExceptionAdvice {

    @ExceptionHandler(UpstreamNotFoundException.class)
    ProblemDetail notFound(UpstreamNotFoundException ex) {
        return ProblemDetail.forStatusAndDetail(HttpStatus.NOT_FOUND, ex.problem().getDetail());
    }

    @ExceptionHandler(UpstreamValidationException.class)
    ProblemDetail invalid(UpstreamValidationException ex) {
        ProblemDetail pd = ProblemDetail.forStatusAndDetail(HttpStatus.BAD_REQUEST, "Upstream rejected the request");
        pd.setProperty("errors", ex.properties().get("errors"));
        return pd;
    }

    @ExceptionHandler({HttpServerErrorException.class, UpstreamUnavailableException.class})
    ProblemDetail badGateway(RuntimeException ex) {
        return ProblemDetail.forStatusAndDetail(HttpStatus.BAD_GATEWAY, "Upstream service error");
    }

    @ExceptionHandler(ResourceAccessException.class)
    ProblemDetail timeout(ResourceAccessException ex) {
        return ProblemDetail.forStatusAndDetail(HttpStatus.GATEWAY_TIMEOUT, "Upstream service timed out");
    }
}

# our service (MockMvc, real HTTP to the stub behind it)
GET /api/posts/1       -> 200 {"id":1,"userId":1,"title":"First post","body":"Body of the first post"}
GET /api/posts/99      -> 404 {"detail":"No post with id 99","instance":"/api/posts/99","status":404,"title":"Not Found"}
POST blank title       -> 400 {"detail":"Upstream rejected the request","instance":"/api/posts","status":400,"title":"Bad Request","errors":[{"field":"title","message":"must not be blank"}]}
GET /api/down          -> 502 {"detail":"Upstream service error","instance":"/api/down","status":502,"title":"Bad Gateway"}
GET /api/slow          -> 504 {"detail":"Upstream service timed out","instance":"/api/slow","status":504,"title":"Gateway Timeout"}

Adding spring-security-oauth2-client secures your own endpoints. The first run of the advice test failed its 200 assertion until I added a permit-all SecurityFilterChain (DemoSecurityConfig.java). The OAuth2 client starter brings Spring Security with Boot’s default “everything needs a login” chain, which applies to your controllers, not just to outgoing calls.

# D. a return type that does not match the JSON (array decoded as a single Post)
list() -> org.springframework.web.client.RestClientException: Error while extracting response for type [com.ankurm.hsc.model.Post] and content type [application/json]
root cause class: tools.jackson.databind.exc.MismatchedInputException

# E. @GetMapping on a client interface instead of @GetExchange
createClient(UsesRequestMapping.class).list() -> java.lang.IllegalStateException: Unexpected method invocation: public abstract java.lang.String com.ankurm.hsc.Step02PropertiesAndPitfallsTest$UsesRequestMapping.list()

Retries: what Spring Framework 7 ships and what it does not

Option 1: @Retryable on the interface method

    /** Retried by Spring Framework 7's @Retryable (needs @EnableResilientMethods): 3 retries, 20 ms apart. */
    @Retryable(includes = HttpServerErrorException.class, maxRetries = 3, delay = 20)
    @GetExchange("/flaky/{key}")
    Post get(@PathVariable String key, @RequestParam int failures);

# 2. @Retryable on the @HttpExchange interface method (bean from the "flaky" group)
get("ann", failures=2) -> 'Recovered on call 3'; stub saw 3 calls
get("ann-dead", failures=10) -> HttpServerErrorException$ServiceUnavailable / 503 Service Unavailable: "{"type":"https://stub.example/problems/service-unavailable","title":"Service Unavailable","status":503,"detail":"Flaky upstream, call 4","instance":"/flaky/ann-dead"}"
stub saw 4 calls (maxRetries = 3)

Option 2: RetryTemplate around the call

# 1. RetryTemplate around the call (org.springframework.core.retry, spring-core 7.0.10)
get("tpl", failures=2) -> 'Recovered on call 3'
stub saw 3 calls; listener events: [beforeRetry, onRetryFailure(ServiceUnavailable), beforeRetry, onRetrySuccess]
maxRetries(2) against a dead upstream -> HttpServerErrorException$ServiceUnavailable / 503 Service Unavailable: "{"type":"https://stub.example/problems/service-unavailable","title":"Service Unavailable","status":503,"detail":"Flaky upstream, call 3","instance":"/flaky/exhaust"}"
stub saw 3 calls
execute() instead of invoke() -> RetryException, retryCount=2, exceptions=3, last=ServiceUnavailable

Option 3: retry once for the whole group, in an interceptor

    public ClientHttpResponse intercept(HttpRequest request, byte[] body, ClientHttpRequestExecution execution)
            throws IOException {
        if (!isIdempotent(request.getMethod())) {
            return execution.execute(request, body);
        }
        try {
            return retryTemplate.execute(() -> {
                attempts.incrementAndGet();
                ClientHttpResponse response = execution.execute(request, body);
                if (response.getStatusCode().is5xxServerError()) {
                    int status = response.getStatusCode().value();
                    response.close();
                    throw new UpstreamUnavailableException(status, "retrying " + request.getMethod() + " " + request.getURI().getPath());
                }
                return response;
            });
        } catch (RetryException e) {
            // retries exhausted: surface the last failure, not the wrapper
            Throwable last = e.getLastException();
            if (last instanceof IOException io) {
                throw io;
            }
            throw (RuntimeException) last;
        }
    }

# 3. the same retry as a ClientHttpRequestInterceptor on the "resilient" group (idempotent methods only)
get("icpt", failures=2) -> 'Recovered on call 3'; stub saw 3 calls; interceptor attempts so far: 3
POST createUnstable -> HttpServerErrorException$ServiceUnavailable / 503 Service Unavailable: "{"type":"https://stub.example/problems/service-unavailable","title":"Service Unavailable","status":503,"detail":"Created, but the response was lost","instance":"/posts/unstable"}"
stub created the resource 1 time(s): the interceptor did not retry a POST

Never retry a POST blindly. I put @Retryable on a POST whose response is lost after the server has done the work. Real output:

# 4. the trap: @Retryable on a POST whose response was lost after the server did the work
createUnstable() -> id 102, body 'created 2 times so far'
stub created the resource 2 times for ONE logical call

# 5. Resilience4j 2.4.0 around the same plain client
maxAttempts(3), failures=2 -> 'Recovered on call 3'; stub saw 3 calls
maxAttempts(3) against a dead upstream -> ServiceUnavailable; stub saw 3 calls

Authentication: bearer tokens, API keys and OAuth2

Bearer token with a ClientHttpRequestInterceptor

    public ClientHttpResponse intercept(HttpRequest request, byte[] body, ClientHttpRequestExecution execution)
            throws IOException {
        request.getHeaders().setBearerAuth(tokens.get());
        return execution.execute(request, body);
    }

    RestClientHttpServiceGroupConfigurer bearerAuth(@Value("${demo.bearer-token}") String token) {
        return groups -> groups.filterByName("bearer").forEachClient((group, builder) ->
                builder.requestInterceptor(new BearerTokenInterceptor(() -> token)));

API key with a property and no Java at all

# 1. no credentials (a plain RestClient)
whoAmI() -> 401 Unauthorized, WWW-Authenticate: Bearer realm="stub"

# 2. bearer token added by a ClientHttpRequestInterceptor on the "bearer" group
whoAmI() -> {caller=demo-user, tokenKind=static}
headers the upstream saw: Authorization=Bearer <redacted>, X-Correlation-Id present=true (8 chars)

# 3. API key from spring.http.serviceclient.apikey.default-header.X-Api-Key (no Java at all)
whoAmI() -> {caller=demo-service, auth=api-key}
headers the upstream saw: X-Api-Key=demo-key-123, X-Correlation-Id present=true

# 4. the interceptor is per group: the "apikey" group never sends Authorization

Do not commit real keys. The values here are fake demo strings. In a real service read them from the environment or a secret store, and prefer the supplier-based interceptor so a rotated token takes effect without a restart. Transcript: 06-auth-bearer-and-api-key.txt.

OAuth2 client credentials with @ClientRegistrationId

@HttpExchange
@ClientRegistrationId("stub")
public interface OAuthClient {

    @GetExchange("/secure/bearer")
    Map<String, String> whoAmI();
}

    OAuth2AuthorizedClientManager authorizedClientManager(ClientRegistrationRepository registrations,
                                                          OAuth2AuthorizedClientService clients) {
        var manager = new AuthorizedClientServiceOAuth2AuthorizedClientManager(registrations, clients);
        manager.setAuthorizedClientProvider(new ClientCredentialsOAuth2AuthorizedClientProvider());
        return manager;
    }

    /** Only the group named in @ClientRegistrationId on the interface gets a token attached. */
    @Bean
    RestClientHttpServiceGroupConfigurer oauthGroups(OAuth2AuthorizedClientManager manager) {
        return OAuth2RestClientHttpServiceGroupConfigurer.from(manager);

# @ClientRegistrationId("stub") on the interface + OAuth2RestClientHttpServiceGroupConfigurer
call 1: whoAmI() -> {caller=demo-user, tokenKind=oauth2}
call 2: whoAmI() -> {caller=demo-user, tokenKind=oauth2}
call 3: whoAmI() -> {caller=demo-user, tokenKind=oauth2}

# what the stub saw, in order
POST /oauth/token
GET /secure/bearer
GET /secure/bearer
GET /secure/bearer
token requests: 1

# the same interface WITHOUT the group configurer: the annotation is silently ignored
whoAmI() -> 401 UNAUTHORIZED

The first version overstated this. It said proxies integrate with Spring Security OAuth2 “without any additional configuration”. Boot does not define the group configurer for you (I listed the auto-configuration imports of spring-boot-security-oauth2-client: nothing for HTTP service groups), so you register it yourself, as above. Transcript: 07-oauth2-client-credentials.txt.

Testing HTTP Service Clients: mock server, slice test and a real server

1. MockRestServiceServer, no Spring context

        RestClient.Builder builder = RestClient.builder().baseUrl(BASE)
                .defaultStatusHandler(s -> s.isError(), new UpstreamProblemStatusHandler());
        MockRestServiceServer server = MockRestServiceServer.bindTo(builder).build();
        PostClient client = HttpServiceProxyFactory.builderFor(RestClientAdapter.create(builder.build()))
                .build().createClient(PostClient.class);

        server.expect(requestTo(BASE + "/posts")).andExpect(method(HttpMethod.POST))
                .andExpect(header("Content-Type", "application/json"))
                .andExpect(jsonPath("$.title").value("New Post"))
                .andExpect(content().json("{\"userId\":1,\"title\":\"New Post\",\"body\":\"Content\"}"))
                .andRespond(withStatus(HttpStatus.CREATED).contentType(MediaType.APPLICATION_JSON)
                        .body("{\"id\":101,\"userId\":1,\"title\":\"New Post\",\"body\":\"Content\"}"));
        Post created = client.create(new Post(null, 1, "New Post", "Content"));

# 1. GET: URL, method and the decoded record
findById(1) -> Post[id=1, userId=1, title=Test Title, body=Test body]

# 2. POST: the request body the interface sent
create(...) -> id 101 (request matched: path, method, Content-Type, JSON body)

# 3. a ProblemDetail 404 goes through the real status handler
findById(9) -> UpstreamNotFoundException (handler decoded the body: 'No post with id 9')

2. @RestClientTest

@RestClientTest(PostClient.class), then @Autowired PostClient -> no such bean (null)

PostClient from the @ImportHttpServices group is injected: true
server.expect(...) -> IllegalStateException: Unable to use auto-configured MockRestServiceServer since a mock server customizer has not been bound to a RestTemplate or RestClient

# a proxy built from the slice's own RestClient.Builder, which the mock server IS bound to
findById(1) -> Post[id=1, userId=1, title=From the mock, body=b]

A mock cannot tell you about timeouts or resets. The first version warned that @RestClientTest passes while staging times out. That is still the lesson: mocks never run the socket, the timeouts or the real serialisation. Baseline your read timeouts from measured latency, and keep real-server tests like the next one.

3. Against a real local server

HTTP Service Clients vs OpenFeign: my honest take after migrating both

The Spring team’s own position. The Spring Cloud OpenFeign README states that the project is treated as feature-complete, that only bug fixes are planned (plus the odd small community PR), and it points users to Spring HTTP Service Clients. The latest GA of spring-cloud-starter-openfeign on Maven Central is 5.0.4. I read the README on 6 November 2026; I did not run Feign in this module.

Feature table

Migrating from OpenFeign

Spring Cloud and Spring Security integration

When to use HTTP Service Clients vs RestClient

Quick reference: all @HttpExchange annotations

The gotcha I hit on day one (save yourself 40 minutes)

Common mistakes to avoid

Should you use this? Yes for calling a handful of well-described REST APIs from a Boot 4 service: the interface is a contract you can read, and the group is where timeouts, auth and retries live. No if you need streaming, highly dynamic URLs or per-call tuning (use RestClient directly), and not as a reason to rip out a stable Feign setup outside a Boot 4 upgrade. Not every claim here covers reactive groups: the WebClient variant (Download hsc-WebClientGroup.java) compiles but was not executed, because it needs spring-webflux.

See also

• Building a REST API with Spring Boot: Complete Beginner’s Guide
• Resilience4j Circuit Breaker in Spring Boot
• Spring Data JPA: Complete Guide
• Mastering Cache Control with ETag in Spring Boot RESTful APIs
• Jackson 101: The Complete Java JSON Tutorial
• Testing Spring REST Clients with @RestClientTest
• Spring Cloud: Creating REST Client Using Feign (legacy approach — compare with this modern alternative)
• Spring Framework 7’s Built-in Resilience: @Retryable, @ConcurrencyLimit
• Global Exception Handling with ProblemDetail (RFC 9457)
• RestTemplate to RestClient Migration Guide

Further reading

• Companion module: http-service-clients (README, tests, every transcript)
• Spring Framework reference: REST clients and HTTP interface clients
• Spring Cloud OpenFeign README (feature-complete notice)
• RFC 9457: Problem Details for HTTP APIs

Frequently Asked Questions

Conclusion