HTTP response caching with Spring WebClient

Question

I am trying to figure out how to cache responses based on the Cache-Control (and related) headers with Spring WebClient. I am aware that caching and a reactive approach do not go naturally hand in hand and that one should use in memory caching.

I see three option that are applicable:

Option 1: Project Reactor provides various cache methods that can be applied on a Mono:

return webClient.get()
        .uri("/hello")
        .retrieve()
        .bodyToMono(HelloWorld.class)
        .cache(Duration.of(3600, ChronoUnit.SECONDS))
        .block();

As the caching happens after the ResponseSpec is turned into the Mono of the entity I loose all information from the headers. There is the option to use toEntity instead:

return webClient.get()
        .uri("/hello")
        .retrieve()
        .toEntity(HelloWorld.class)
        .cache(Duration.of(3600, ChronoUnit.SECONDS))
        .block().getBody();

But I cannot figure out how to access the ResponseEntity from within the cache method. Would something like this work?

return webClient.get()
        .uri("/hello")
        .retrieve()
        .toEntity(HelloWorld.class)
        .flatMap(response ->
             Mono.just(response).cache(getTtlFromHeader(response.getHeaders()))
        )
        .block().getBody();

Based on the JavaDoc of cache I gather:

• ttlForValue - the TTL-generating Function invoked when source is valued: Should be cached as the response
• ttlForError - the TTL-generating Function invoked when source is erroring: Should not be cached
• ttlForEmpty - the TTL-generating Supplier invoked when source is empty: Nothing can be cached anyway

With any of the alternatives based on the Mono I do not have a handle to reevaluate if the cached response is still valid.

Option 2: Implement the caching functionality through a filter. This means that the cached object is the Mono of the response instead of the response itself. While I have not tried this it seems to me that is not optimal, as the Mono is resolved after the first call, and would need to be resolved even when retrieved from the cache. It is also not that clear how to handle the need to reevaluate cached data. This leaves me with the impression, that while it is possible to achieve it through a filter it would be quite a complex one.

Option 3: Handle the caching outside of the WebClient call. As in my case all calls invoke a blocking subscriber so that the surrounding logic is non-reactive, the caching could be handled with Spring caching given that the ResponseEntity is returned instead of just the response object.

I dislike this idea as the ResponseEntity escapes the WebClient call and I want to encapsulate everything that is specific to the call in there.

Option 4: As I am using an Apache Async client as the underlying client connector I could switch from:

private CloseableHttpAsyncClient httpClient(int maxTotalConnections, int maxConnectionsPerRoute) {
    return HttpAsyncClients.custom()
            .setConnectionManager(connectionManager(maxTotalConnections, maxConnectionsPerRoute))
            .disableCookieManagement()
            .evictExpiredConnections()
            .disableRedirectHandling()
            .build();
}

to

private CloseableHttpAsyncClient cachableHttpClient(int maxTotalConnections, int maxConnectionsPerRoute) {
    CacheConfig cacheConfig = CacheConfig.DEFAULT;
    return CachingHttpAsyncClients.custom()
            .setCacheConfig(cacheConfig)
            .setConnectionManager(connectionManager(maxTotalConnections, maxConnectionsPerRoute))
            .disableCookieManagement()
            .evictExpiredConnections()
            .disableRedirectHandling()    
            .build();
}

Probably with a bit more looking into the CacheConfig. This seems the best solution, however verifying that it works through automated tests will be very hard.

---

• Are there other options that I overlooked?
• What is the preferred way to do it?