Add portable Http Connector Engine interface

Question

Add portable Http Connector Engine interface

Opened this issue 2 months ago · 12 comments

Currently, we(the end developers) do not know which the rest clients use which HTTP Client library in the background, like the issue I mentioned in #1276, we need to add more provider-specific properties to use it.

I would like use a more fine-grained configuration on the background HttpClient itself directly.

Expose a HttpConnector interface to allow developers to customize it as expected.

ClientBuilder.httpConnector(
custom JdkHttpClientHttpConnector
or ApacheHttpClientHttpConnector
or JettyClientHttpConnector
or NettyClientHttpConnector
etc...
)

For example, JdkHttpClientHttpConnector can be instantize simply as the following.

new JdkHttpClientHttpConnector(); // create a built-in JDK 11 HttpClient internally.

Or accept a your custom JDK 11 HttpClient.

var executorService = Executors.newFixedThreadPool(5);
var httpClient = HttpClient.newBuilder()
            .executor(executorService)
            .version(HttpClient.Version.HTTP_2)
            .build();

new JdkHttpClientHttpConnector(httpClient);

Answer 1 · 2024-08-31T09:07:52.000Z

What shall vendors do that currently are JAX-RS compatible, but that do not have replaceable backends, but just one hardcoded backend? Shall they not be JAX-RS compatible anymore or do you pay their costs for reworking their kernel to support replaceable backends?

Having said that, wouldn't it be enough to mandata that IF a vendor supports replaceable backends, then they MUST support predefined properties to configure them?

Answer 2 · 2024-09-02T01:02:44.000Z

I hope the spec provider can provide their HttpConnector implementations freely, but at least give an implementation based on JDK 11 HttpClient, and make it the default implementation(for the end users, we do not need to add more dependencies).

The end user can also implement its own HttpConnector impl to replace the one in the provider. For example, in one project, we use OkHttp as an HTTP client to handle all client cases, but this Jaxrs provider does not provide an OKHttp version, to align with our codes and we do not want to introduce new dependencies, we can impl a HttpConnector based on OkHttp.

Answer 3 · 2024-09-02T19:34:00.000Z

@hantsy Can you try to prototype some way to hook in the connector? It is not clear to me what simply new JdkHttpClientHttpConnector(httpClient); would do to deliver the response. Do you mean some static approach or some other way?

Answer 4 · 2024-09-02T20:41:13.000Z

I hope the spec provider can provide their HttpConnector implementations freely, but at least give an implementation based on JDK 11 HttpClient, and make it the default implementation(for the end users, we do not need to add more dependencies).

The end user can also implement its own HttpConnector impl to replace the one in the provider. For example, in one project, we use OkHttp as an HTTP client to handle all client cases, but this Jaxrs provider does not provide an OKHttp version, to align with our codes and we do not want to introduce new dependencies, we can impl a HttpConnector based on OkHttp.

This imposes strong restrictions on how a JAX-RS implementation is actually designed -- something that an API shall never do.

Answer 5 · 2024-09-03T02:10:54.000Z

something that an API shall never do.
Like the Jakarta Rest spec, there are several impls, such as Eclipse Jersey, Resteasy etc.

It is not just an API, in the end user's mind, it is a framework, that should be provide more flexible options.

Answer 6 · 2024-09-03T02:22:04.000Z

@hantsy Can you try to prototype some way to hook in the connector? It is not clear to me what simply new JdkHttpClientHttpConnector(httpClient); would do to deliver the response. Do you mean some static approach or some other way?

The new Spring 6.x provides a RestClient, and Spring also provided a WebClient since 5.x. Unlike the former client tools(eg. restTemplate), they offer a configurable option to switch the background HTTP Client engine and allow developers to configure HTTP Message codecs details.

Check the following docs for more details.

The ClientHttpRequestFactory used to build a RestClient(Blocking API), https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/http/client/ClientHttpRequestFactory.html
The ClientHttpConnector used to build a WebClient(Reactive API), https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/http/client/reactive/ClientHttpConnector.html

Answer 7 · 2024-09-04T18:04:43.000Z

It is not just an API, in the end user's mind, it is a framework, that should be provide more flexible options.

Jakarta REST is not a framework, it is just an API.

Answer 8 · 2024-09-04T18:06:30.000Z

I think if we adopt this idea, then there should be a separate Jakarta subprojekt for defining such an API that we can build upon.

Answer 9 · 2024-09-11T23:50:11.000Z

One thing to point out is the JDK HTTP Client doesn't implement everything needed to work with the jakara.ws.rs.client.Client. For example, the Jakarta REST Client allows the a hostname verifier to be set which you cannot do on the JDK's HTTP Client. I proposed we deprecate that, but it's a breaking change and was rejected.

FWIW RESTEasy does this with an SPI already, so it would work for RESTEasy.

That said, I don't think the Jakarta REST API should provide any implementations, nor should they be required to even implement one. I can see this useful to an end user where they might want to use some custom HTTP client.

Answer 10 · 2024-09-12T06:11:24.000Z

I think if we adopt this idea, then there should be a separate Jakarta subprojekt for defining such an API that we can build upon.

I do not think so.

Jakarta Rest Client itself can use switchable serialization/deserialization providers, filters, portable rx invokers, etc., so why the HTTP client should be a subproject?

Answer 11 · 2024-09-12T06:12:48.000Z

FWIW RESTEasy does this with an SPI already, so it would work for RESTEasy.

If possible to port this to the public Rest specification?

Answer 12 · 2024-09-13T16:57:27.000Z

I think if we adopt this idea, then there should be a separate Jakarta subprojekt for defining such an API that we can build upon.

I do not think so.

Jakarta Rest Client itself can use switchable serialization/deserialization providers, filters, portable rx invokers, etc., so why the HTTP client should be a subproject?

Because it makes sense to have the same interface whereever pure HTTP services are needed. Jakarta REST is just a REST API, not a generic HTTP client. What we need here is not a REST-only API, but a pure HTTP API. It makes sense that other projects (even non-Jakarta-projects) make use of this. In fact, it should be defined by the vendors of these HTTP Clients, not the the consuming REST engines.