Springboot : How to use WebClient instead of RestTemplate for Performing Non blocking and Asynchronous calls

Due to the fact that there are lot of misconception, so here I'm going to clear up some things.

Spring has officially stated that they will deprecate RestTemplate in the future so if you can, use WebClient if you want to be as future proof as possible.

as stated in the RestTemplate API

NOTE: As of 5.0, the non-blocking, reactive org.springframework.web.reactive.client.WebClient offers a modern alternative to the RestTemplate with efficient support for both sync and async, as well as streaming scenarios. The RestTemplate will be deprecated in a future version and will not have major new features added going forward. See the WebClient section of the Spring Framework reference documentation for more details and example code.

Non reactive application

If your application is a non-reactive application (not returning fluxes or monos to the calling clients) what you have to do is to use block() if you need the value. You can of course use Mono or Flux internally in your application but in the end you must call block() to get the concrete value that you need to return to the calling client.

Non reactive applications use tomcat as the underlying server implementation, which is a servlet based server that will assign 1 thread per request so you will not gain the performance gains you get with a reactive application.

Reactive application

If you on the other hand you have a reactive application you should never under any circumstances ever call block() in your application. Blocking is exactly what it says, it will block a thread and block that threads execution until it can move on, this is bad in a reactive world.

You should also not call subscribe in your application unless your application is the final consumer of the response. For instance, if you are calling an api to get data and write into a database that your application is connected to. Your backend application is the final consumer. If an external client is calling your backend (for instance an react, angular app, mobile client, etc. etc.) the external client is the final consumer, and is the one subscribing. Not you.

Underlying default server implementation here is a netty server which is a non servlet, event based server that will not assign one thread to each request, the server itself is thread agnostic and any thread available will handle anything at any time during any request.

The webflux documentation clearly states that both servlet 3.1+ supported servers tomcat and jetty can be used with webflux as well as non-serlet servers netty and undertow.

How do i know what application i have?

Spring states that if you have both spring-web and spring-webflux on the classpath, the application will favor spring-web and per default start up a non-reactive application with an underlying tomcat server.

This behaviour can manually be overridden if needed as spring states.

Adding both spring-boot-starter-web and spring-boot-starter-webflux modules in your application results in Spring Boot auto-configuring Spring MVC, not WebFlux. This behavior has been chosen because many Spring developers add spring-boot-starter-webflux to their Spring MVC application to use the reactive WebClient. You can still enforce your choice by setting the chosen application type to SpringApplication.setWebApplicationType(WebApplicationType.REACTIVE).

The “Spring WebFlux Framework”

So how to implement WebClient

@Retryable(maxAttempts = 4,
       value = java.net.ConnectException.class,
       backoff = @Backoff(delay = 3000, multiplier = 2))
public ResponseEntity<String> getResponse(String url) {
    return webClient.get()
            .uri(url)
            .exchange()
            .flatMap(response -> response.toEntity(String.class))
            .block();
}

This is the easiest and the most less intrusive implementation. You ofcourse need to build a proper webclient in maybe a @Bean and autowire it into its class.

The first thing to understand is if you are needing to call .block() you might as well stick with RestTemplate, using WebClient will gain you nothing.

You need to start thinking in reactive terms if you want to gain from using WebClient. A reactive process is really just a sequence of steps, the input of each step being the output of the step before it. When a request comes in, your code creates the sequence of steps and returns immediately releasing the http thread. The framework then uses a pool of worker threads to execute each step when the input from the previous step becomes available.

The benefit is a huge gain in capacity to accept competing requests at the small cost of having to rethink the way you write code. Your application will only need a very small pool of http threads and another very small pool of worker threads.

When your controller method is returning a Mono or Flux, you have got it right and there will be no need to call block().

Something like this in it's simplest form:

@GetMapping(value = "endpoint", produces = MediaType.TEXT_PLAIN_VALUE)
@ResponseBody
@ResponseStatus(OK)
public Mono<String> controllerMethod() {

    final UriComponentsBuilder builder =
            UriComponentsBuilder.fromHttpUrl("http://base.url/" + "endpoint")
                    .queryParam("param1", "value");

    return webClient
            .get()
            .uri(builder.build().encode().toUri())
            .accept(APPLICATION_JSON_UTF8)
            .retrieve()
            .bodyToMono(String.class)
            .retry(4)
            .doOnError(e -> LOG.error("Boom!", e))
            .map(s -> {

                // This is your transformation step. 
                // Map is synchronous so will run in the thread that processed the response. 
                // Alternatively use flatMap (asynchronous) if the step will be long running. 
                // For example, if it needs to make a call out to the database to do the transformation.

                return s.toLowerCase();
            });
}

Moving to thinking in reactive is a pretty big paradigm shift, but well worth the effort. Hang in there, it's really not that difficult once you can wrap your head around having no blocking code at all in your entire application. Build the steps and return them. Then let the framework manage the executions of the steps.

Happy to provide more guidance if any of this is not clear.

Remember to have fun :)