Add portable Http Connector Engine interface

[hantsy]

Add portable Http Connector Engine interface

[mkarg]

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?

[hantsy]

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.

[jansupol]

@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?

[mkarg]

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.

[hantsy]

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.

[hantsy]

@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

[mkarg]

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.

[mkarg]

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.