[Feature Request] Design pattern strategy / factory / else to choose the actual http client.

[patpatpat123]

Description

Hello Elastic team,

I would like to reach out to ask for a possible enhancement request.

As of today, looking at the code, this elasticsearch-java is using a rest client based on apache http client.
Looking at the code, this apache http client is tightly coupled, meaning, there are as of now no possibilities to provide or swap to another http client.

This post is not to debate which http client is the best by the way.

But there are several http clients in the market (okhttp, netty client) which sometimes offer better performances, as well as many interesting features (wiretap logging, built-in metrics to name a few).
If not features, many companies have their preferences in terms of which client to use in order to send requests.

Therefore, would it be possible to propose some kind of pattern, or design, from elasticsearch-java which can ease having a custom http client instead?

The default can definitely be the current http client, but looking at the current architecture, it is used mainly to make a request, send it over the wire, and get the http response. This is the baseline for any other http client.

I am not asking if it is possible for this project to support each and every imaginable client, but just to allow the user to specify his.

Some kind of design pattern strategy, factory, or another approach to allow a user to specify his own client would bring benefit to this project.

Thank you

[swallez]

Thanks for this suggestion @patpatpat123. Actually this abstraction already exists, it's the Transport interface.

It currently has only one implementation based on the Low Level Rest Client (LLRC): RestClientTransport. There are several reasons for this initial (and currently only) implementation:

• development time: it has been battle tested for years and handles Elasticsearch-specific features on top of the Apache Http client library, such as retries and node selection
• smooth migration path for existing applications, by allowing the same Low Level Rest Client to be shared between a Java API client and existing code using the High Level Rest Client. This ensures both clients will use the same connection pool.

We have considered additional implementations based on Java 11's builtin http client and the latest apache http client, which will also provide utilities to handle ES-specific features provided by LLRC but this work hasn't been added to the roadmap yet.