Reactive Systems in Java

Chapter 8. HTTP with Reactive in Mind

Even when building a reactive system, HTTP is unavoidable. HTTP is a prevalent protocol, and REST, for instance, is a well-known approach to designing services and APIs. The problem with HTTP, as mentioned in Chapter 4, is the request/response interaction scheme that leads to undesirable time coupling. Also, to implement space decoupling, you often need proxies that would route the requests or advanced service discovery and load-balancing mechanism.

But let’s face it: we need to be pragmatic, and HTTP has plenty of great features. We recommend using HTTP at the edge of your system (the places interacting with external entities), as shown in Figure 8-1 For example, HTTP is often used on the front tier to expose an API easily consumable by other external services. Besides, we often use HTTP at the various integration points with other external services, such as consuming services exposed using a REST API.

Integrating HTTP should not prevent or limit the responsiveness of the reactive system you are building. As a consequence, we need to implement this integration carefully. It’s not rare to see a system using a so-called asynchronous HTTP client, which can do more harm than provide benefits as it may rely on a hidden thread pool.

Figure 8-1. Using HTTP at the edge of a reactive system

This chapter explores the features Quarkus offers to expose ...