How to Make Multiple REST Calls in CompletableFuture

1. Introduction

When creating software capabilities, an everyday activity is retrieving data from different sources and aggregating it in the response. In microservices, those sources are often external REST APIs.

In this tutorial, we’ll use Java’s CompletableFuture to efficiently retrieve data from multiple external REST APIs in parallel.

2. Why Use Parallelism in REST Calls

Let’s imagine a scenario where we need to update various fields in an object, each field value coming from an external REST call. One alternative is to call each API sequentially to update each field.

However, waiting for one REST call to complete to start another increases our service’s response time. For instance, if we call two APIs that take 5 seconds each, the total time would be at least 10 seconds since the second call needs to wait for the first to complete.

Instead, we can call all APIs in parallel so that the total time would be the time of the slowest REST call. For example, one call takes 7 seconds, and another 5 seconds. In that case, we’ll wait 7 seconds since we have processed everything in parallel and must wait for all the results to complete.

Hence, parallelism is an excellent alternative to reduce our services’ response times, making them more scalable and improving user experience.

3. Using CompletableFuture for Parallelism

The CompletableFuture class in Java is a handy tool for combining and running different parallel tasks and handling individual task errors.

In the following sections, we’ll use it to combine and run three REST calls for each object in an input list.

3.1. Creating the Demo Application

Let’s first define our target POJO for updates:

public class Purchase {
    String orderDescription;
    String paymentDescription;
    String buyerName;
    String orderId;
    String paymentId;
    String userId;

    // all-arg constructor, getters and setters
}

The Purchase class has three fields that should be updated, each one by a different REST call queried by an ID.

Let’s first create a class that defines a RestTemplate bean and a domain URL for the REST calls:

@Component
public class PurchaseRestCallsAsyncExecutor {
    RestTemplate restTemplate;
    static final String BASE_URL = "https://internal-api.com";

    // all-arg constructor
}

Now, let’s define the /orders API call:

public String getOrderDescription(String orderId) {
    ResponseEntity<String> result = restTemplate.getForEntity(String.format("%s/orders/%s", BASE_URL, orderId),
        String.class);

    return result.getBody();
}

Then, let’s define the /payments API call:

public String getPaymentDescription(String paymentId) {
    ResponseEntity<String> result = restTemplate.getForEntity(String.format("%s/payments/%s", BASE_URL, paymentId),
        String.class);

    return result.getBody();
}

And finally, we define the /users API call:

public String getUserName(String userId) {
    ResponseEntity<String> result = restTemplate.getForEntity(String.format("%s/users/%s", BASE_URL, userId),
        String.class);

    return result.getBody();
}

All three methods use the getForEntity() method to make the REST call and wrap the result in a ResponseEntity object.

Then, we call getBody() to get the response body from the REST call.

3.2. Making Multiple REST Calls With CompletableFuture

Now, let’s create the method that builds and runs a set of three CompletableFutures:

public void updatePurchase(Purchase purchase) {
    CompletableFuture.allOf(
      CompletableFuture.supplyAsync(() -> getOrderDescription(purchase.getOrderId()))
        .thenAccept(purchase::setOrderDescription),
      CompletableFuture.supplyAsync(() -> getPaymentDescription(purchase.getPaymentId()))
        .thenAccept(purchase::setPaymentDescription),
      CompletableFuture.supplyAsync(() -> getUserName(purchase.getUserId()))
        .thenAccept(purchase::setBuyerName)
    ).join();
}

We used the allOf() method to build the steps of our CompletableFuture. Each argument is a parallel task in the form of another CompletableFuture built with the REST call and its result.

To build each parallel task, we first used the supplyAsync() method to provide the Supplier from which we’ll retrieve our data. Then, we use thenAccept() to consume the result from supplyAsync() and set it on the corresponding field in the Purchase class.

At the end of allOf(), we’ve just built the tasks up to there. No action was taken.

Finally, we call join() at the end to run all tasks in parallel and collect their results. Since join() is a thread-blocking operation, we only call it at the end instead of at each task step. This is to optimize the application performance by having fewer thread blocks.

Since we didn’t provide a customized ExecutorService to the supplyAsync() method, all tasks run in the same executor. By default, Java uses ForkJoinPool.commonPool().

In general, it’s a good practice to specify a custom ExecutorService to supplyAsync() so we will have more control over our thread pool parameters.

3.3. Executing Multiple REST Calls for Each Element in a List

To apply our updatePurchase() method on a collection, we can simply call it in a forEach() loop:

public void updatePurchases(List<Purchase> purchases) {
    purchases.forEach(this::updatePurchase);
}

Our updatePurchases() method receives a list of Purchases and applies the previously created updatePurchase() method to each element.

Each call to updatePurchases() runs three parallel tasks as defined in our CompletableFuture. Hence, each purchase has its own CompletableFuture object to run the three parallel REST calls.

4. Handling Errors

In distributed systems, it’s pretty common to have service unavailability or network failures. Those failures might happen in external REST APIs that we, as the clients of that API, are unaware of. For instance, if the application is down, the request sent over the wire never completes.

4.1. Handling Errors Gracefully Using handle()

Exceptions may occur during the REST call execution. For instance, if the API service is down or if we input invalid parameters, we’ll get errors.

Hence, we can handle each REST call exception individually using the handle() method:

public <U> CompletableFuture<U> handle(BiFunction<? super T, Throwable, ? extends U> fn)

The method argument is a BiFunction containing the result and the exception from the previous task as arguments.

To illustrate, let’s add the handle() step into one of our CompletableFuture‘s steps:

public void updatePurchaseHandlingExceptions(Purchase purchase) {
    CompletableFuture.allOf(
        CompletableFuture.supplyAsync(() -> getPaymentDescription(purchase.getPaymentId()))
          .thenAccept(purchase::setPaymentDescription)
          .handle((result, exception) -> {
              if (exception != null) {
                  // handle exception
                  return null;
              }
              return result;
          })
    ).join();
}

In the example, handle() gets a Void type from setPaymentDescription() called by thenAccept().

Then, it stores in exception any error thrown inside the thenAccept() actions. Hence, we used it to check for an error and handle it properly in the if statement.

Finally, handle() returns the value passed as an argument if no exception was thrown. Otherwise, it returns null.

4.2. Handling REST Call Timeouts

When we work with CompletableFuture, we can specify a task timeout similar to the one we define in our REST calls. Hence, if a task isn’t completed in the specified time, Java finishes the task execution with a TimeoutException.

To do that, let’s modify one of our CompletableFuture’s tasks to handle timeouts:

public void updatePurchaseHandlingExceptions(Purchase purchase) {
    CompletableFuture.allOf(
        CompletableFuture.supplyAsync(() -> getOrderDescription(purchase.getOrderId()))
          .thenAccept(purchase::setOrderDescription)
          .orTimeout(5, TimeUnit.SECONDS)
          .handle((result, exception) -> {
              if (exception instanceof TimeoutException) {
                  // handle exception
                  return null;
              }
              return result;
          })
    ).join();
}

We’ve added the orTimeout() line to our CompletableFuture builder to stop the task execution abruptly if it doesn’t complete in 5 seconds.

We’ve also added an if statement in the handle() method to handle TimeoutException separately.

Adding timeouts to CompletableFuture guarantees that the task always finishes. This is important to avoid a thread hanging indefinitely, waiting for the result of an operation that may never finish. Therefore, it decreases the number of threads in a long-time RUNNING state and increases the application’s health.

5. Conclusion

A common task when working with distributed systems is to make REST calls to different APIs to build a proper response.

In this article, we’ve seen how to use CompletableFuture to build a set of parallel REST call tasks for every object in a collection.

We’ve also seen how to handle timeouts and general exceptions gracefully using the handle() method.