Reactive Systems in Java

Chapter 12. Reactive REST Client: Connecting with HTTP Endpoints

The previous two chapters focused on messaging, the connective tissue of reactive systems. Modern message brokers provide the perfect feature set to implement the internal communication of reactive systems. However, at the frontier of your system, where you need to integrate remote services, there’s a good chance you need to use HTTP. So let’s be pragmatic and see how we can consume HTTP services without breaking the reactive principles.

In Chapter 8, you saw how to expose reactive HTTP endpoints. This chapter presents the other side: how to consume HTTP endpoints. Quarkus offers a nonblocking way to consume HTTP endpoints. In addition, it provides resilience features to protect the integration points against failures and slowness. It’s important to notice that the called service does not have to be a reactive application. That’s up to the implementation of that service.

Let’s see what Quarkus offers to consume HTTP endpoints.

Interacting with an HTTP Endpoint

Quarkus provides multiple ways to consume HTTP endpoints:

Vert.x Web Client

This low-level HTTP client is implemented on top of Vert.x and Netty (and so is inherently asynchronous and based on nonblocking I/O).

Reactive Messaging connector

This connector sends HTTP requests for each processed message.

REST client

This type-safe approach eases the consumption of HTTP-based APIs.

Vert.x Web Client is convenient when you don’t want to bother being exposed ...