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 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month, and much more.
