HttpClient Spring 7: reemplazo de Feign

HttpClient declarativo de Spring 7: alternativa a FeignClient

Spring 7 introduce un HttpClient declarativo nativo basado en RestClient y WebClient. Utiliza anotaciones familiares como @GetExchange y @PostExchange, similares a @GetMapping en controladores. Esto permite definir peticiones HTTP salientes mediante interfaces sin implementación manual.

Así se ve la interfaz principal:

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 se integra con observabilidad de forma nativa y no requiere Spring Cloud, a diferencia de FeignClient, que está en modo mantenimiento desde 2022.

Integración con OpenAPI Generator

Para generar clientes automáticamente, usa openapi-generator con la librería spring-http-interface.

Configuración del plugin Maven:

<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>

Esto genera una interfaz como:

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

Conexión y configuración de servicios

Configuración mediante importación:

@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") 
    );    
  }  
}

El manejo de errores se configura mediante defaultStatusHandler:

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

Un HttpErrorHandler personalizado permite adaptar la lógica para códigos 4xx/5xx, integrarse con Resilience4j o usar @ControllerAdvice.

Características clave:

• Configuración de interceptores
• Integración con Resilience4j
• Manejo de errores a nivel ResponseSpec

RestClient vs WebClient con Project Loom

Con hilos virtuales (spring.threads.virtual.enabled=true), RestClient bloqueante ofrece escalabilidad I/O sin programación reactiva.

Ventajas:

• Código imperativo fácil de depurar
• Sin pipelines reactivos
• Rendimiento comparable a WebClient en tareas I/O

Para escenarios reactivos, selecciona WebClient.Builder para generar firmas Mono/Flux.

Desafíos de validación y soluciones

Bean Validation no recorre objetos anidados porque el generador omite @Valid.

Soluciones:

• x-field-extra-annotation en OpenAPI: @jakarta.validation.Valid — requiere cambios en la especificación.
• AlwaysTraversableResolver — recorre todo el árbol de objetos globalmente, pero arriesga ciclos y afecta rendimiento.
• Plantillas Mustache personalizadas — añade @Valid automáticamente durante la generación.

Extra: Genera clases de datos Kotlin para seguridad con nulos.

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

Dependencias: kotlin-stdlib + jackson-module-kotlin. Deserialización con fallo rápido ante violaciones de nulabilidad.

Conclusiones clave

• HttpClient es nativo de Spring Framework, sin dependencias de Spring Cloud.
• OpenAPI Generator con spring-http-interface produce interfaces listas para usar.
• Hilos virtuales simplifican I/O sin reactividad.
• Clases de datos Kotlin detectan problemas de nulos tempranamente.
• Manejo de errores y validación totalmente personalizables.

— Editorial Team