Provide new API to programmatically create REST Client reactive

[Sgitario]

Description

When creating a REST Client reactive programmatically, we use the Microprofile API RestClientBuilder as:

var myClient = RestClientBuilder.newBuilder().baseUri(URI.create(uri)).build(Client.class);

However, having to use the Microprofile API limits the ability of Quarkus to programmatically configure some features, so this issue is about providing our Quarkus-specific RestClientBuilder API.

At the moment, the additional options would include:

• verifyHost
• trustStore by truststore and password (it was requested in Fix truststore REST Client config when password is not set #31891 (comment))
• proxyUser
• proxyPassword
• nonProxyHosts

In next iterations, we could extend the API with:

• clientHeadersFactory (requested by Support registering a ClientHeadersFactory in the rest client programmatic API #32189)
• clientRequestFilter
• redirectHandler
• httpClientOptions: Support registering a HttpClientOptions in REST Client Reactive API #32881
• ...

Implementation ideas

No response

[quarkus-bot]

/cc @cescoffier (rest-client), @geoand (rest-client)

[geoand]

I'm +1 for this.

@radcortez do you think this should be Quarkus specific or something we can have in Smallrye?

[radcortez]

SmallRye doesn't provide the REST Client implementation (it used to, but it was moved to RESTEasy).

My recommendation is to do it in RESTEasy.

[geoand]

That wouldn't allow us however to share it for RESTEasy Reactive and RESTEasy Classic.

It would definitely be easier at this point to have this be Quarkus specific and only have it apply to RESTEasy Reactive

[Sgitario]

That wouldn't allow us however to share it for RESTEasy Reactive and RESTEasy Classic.

It would definitely be easier at this point to have this be Quarkus specific and only have it apply to RESTEasy Reactive

Note that we will keep supporting the existing Microprofile API. The idea is to provide a new Quarkus-specific API to extend the options to configure the REST Client Reactive.

[radcortez]

And do we want to exclude RESTEasy Classic?

[Sgitario]

And do we want to exclude RESTEasy Classic?

We could provide another API for RESTEasy Classic, with the supported options for only RESTEasy Classic, but I would keep our efforts to improve the user experience on RESTEasy Reactive for now.

[geoand]

but I would keep our efforts to improve the user experience on RESTEasy Reactive for now

+1

[usr000]

Also very interested in the functionality.
Some additional ideas for features:

1. Ability to reuse Quarkus out of the box instrumentation - e.g for tracing/context propagation
2. Ability for multiple clients to share the underlying resources - e.g. set max connection pool, and then when creating a client - supply this same connection pool.