HttpClient Spring 7: Feign-Ersatz

Spring 7: Der deklarative HttpClient als FeignClient-Alternative

Spring 7 führt einen nativen deklarativen HttpClient ein, der auf RestClient und WebClient basiert. Er nutzt vertraute Annotationen wie @GetExchange und @PostExchange, ähnlich wie @GetMapping in Controllern. So können ausgehende HTTP-Anfragen über Interfaces definiert werden – ohne manuelle Implementierung.

So sieht die zentrale Schnittstelle aus:

public interface UserClient {

    @GetExchange("/api/users/{id}")
    UserResponse getUser(
        @PathVariable("id") Long id,
        @RequestParam(name = "includeDetails", defaultValue = "false") boolean includeDetails,
        @RequestHeader("Authorization") String authToken,
        @RequestHeader("X-Request-Id") String requestId
    );

    @PostExchange("/api/users")
    UserResponse createUser(
        @RequestBody @Valid CreateUserRequest request,
        @RequestHeader("Authorization") String authToken
    );

    @PatchExchange("/api/users/{id}")
    void updateUserEmail(
        @PathVariable("id") Long id,
        @RequestParam("email") String email,
        @RequestHeader("Authorization") String authToken
    );
}

HttpClient integriert sich out-of-the-box mit Observability und benötigt kein Spring Cloud – im Gegensatz zu FeignClient, der seit 2022 nur noch im Wartungsmodus ist.

Integration mit OpenAPI Generator

Für automatisierte Client-Generierung: openapi-generator mit der Bibliothek spring-http-interface.

Maven-Plugin-Konfiguration:

<plugin>
    <groupId>org.openapitools</groupId>
    <artifactId>openapi-generator-maven-plugin</artifactId>
    <version>${openapi-generator.version}</version>
    <executions>
       <execution>
    <id>generate-weather-client</id>
    <goals>
       <goal>generate</goal>
    </goals>
    <configuration>
       <inputSpec>${project.basedir}/src/main/resources/openapi/external/weather-api.yaml</inputSpec>
       <generatorName>spring</generatorName>
       <library>spring-http-interface</library>
       <output>${project.build.directory}/generated-sources/openapi-client</output>
       <apiPackage>ulllie.exchange.openapi.gen.client.api</apiPackage>
       <modelPackage>ulllie.exchange.openapi.gen.client.model</modelPackage>
       <generateApis>true</generateApis>
       <generateModels>true</generateModels>
       <generateSupportingFiles>false</generateSupportingFiles>
       <configOptions>
          <useSpringBoot4>true</useSpringBoot4>
          <useJackson3>true</useJackson3>
          <interfaceOnly>true</interfaceOnly>
          <skipDefaultInterface>true</skipDefaultInterface>
          <useBeanValidation>true</useBeanValidation>
          <annotationLibrary>none</annotationLibrary>
          <serializationLibrary>jackson</serializationLibrary>
          <useTags>true</useTags>
       </configOptions>
    </configuration>
</execution>
    </executions>
</plugin>

Daraus entsteht eine Schnittstelle wie:

public interface OpenMeteoApi { 
  @HttpExchange(method = "GET", value = "/v1/forecast")   
  ResponseEntity<ForecastResponse> getForecast( 
    @RequestParam("latitude") Double latitude, 
    @RequestParam("longitude") Double longitude 
  );
}

Services verbinden und konfigurieren

Konfiguration per Import:

@Configuration  @ImportHttpServices(group = "weather", types = OpenMeteoApi.class)  
public class WeatherRestClientConfig implements RestClientHttpServiceGroupConfigurer {    
  @Override      
  public void configureGroups(Groups<RestClient.Builder> groups) { 
    groups.filterByName("weather").forEachClient(
      ($, builder) -> builder.baseUrl("https://api.weather.com") 
    );    
  }  
}

Fehlerbehandlung via defaultStatusHandler:

builder.baseUrl(properties.baseUrl())
  .defaultStatusHandler(
  status -> status.is4xxClientError() || status.is5xxServerError(),               
  errorHandler         
);

Ein eigener HttpErrorHandler erlaubt maßgeschneiderte Logik für 4xx/5xx-Codes, Integration mit Resilience4j oder Nutzung von @ControllerAdvice.

Wichtige Features:

• Interceptor-Konfiguration
• Resilience4j-Integration
• Fehlerbehandlung auf ResponseSpec-Ebene

RestClient vs. WebClient mit Project Loom

Mit Virtual Threads (spring.threads.virtual.enabled=true) liefert der blockierende RestClient I/O-Skalierbarkeit – ohne reaktive Programmierung.

Vorteile:

• Imperativer Code, leicht zu debuggen
• Keine reaktiven Pipelines
• Performance wie WebClient bei I/O-lastigen Tasks

Für reaktive Szenarien: WebClient.Builder für Mono/Flux-Signaturen wählen.

Validierungs-Herausforderungen und Lösungen

Bean Validation rekurriert nicht in verschachtelte Objekte, da der Generator @Valid überspringt.

Lösungen:

• x-field-extra-annotation in OpenAPI: @jakarta.validation.Valid – erfordert Spec-Änderungen.
• AlwaysTraversableResolver – durchläuft den gesamten Objektbaum global, riskiert aber Zyklen und Performanceeinbußen.
• Eigene Mustache-Templates – fügt @Valid automatisch bei der Generierung hinzu.

Bonus: Kotlin-Data-Classes für Null-Safety generieren.

data class ForecastResponse(
  val temperature: Double,
  val windSpeed: Double?
)

Dependencies: kotlin-stdlib + jackson-module-kotlin. Fail-fast-Deserialisierung bei Null-Verletzungen.

Wichtige Erkenntnisse

• HttpClient ist nativ im Spring Framework – keine Spring Cloud-Abhängigkeiten.
• OpenAPI Generator mit spring-http-interface erzeugt einsatzbereite Interfaces.
• Virtual Threads vereinfachen I/O ohne Reaktivität.
• Kotlin-Data-Classes fangen Null-Probleme früh ab.
• Fehlerbehandlung und Validierung voll anpassbar.

— Editorial Team