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

Question

I have a springboot project which uses Springboot Resttemplate. We have moved to springboot 2.0.1 from 1.5.3 and we are trying to make the rest calls from it asynchronous by us

Answer 1

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