RestClientProcessor should support parameterized providers/filters

[cortex93]

Description

Currently RestClientProcessor only support class-based registration of providers and I can't find a way to pass per method configuration. The idea would be to able to do something like :

@RegisterRestClient
@Path("/")
public interface ProtectedResourceService {

    @GET
    @RegisterProvider(CustomRequestFilter.class, "foo", "apple")
    String getWithFoo();

    @GET
    @RegisterProvider(CustomRequestFilter.class, "bar", "banana")
    String getWithBar();
}

or using annotations

@RegisterRestClient
@Path("/")
public interface ProtectedResourceService {

    @GET
    @CustomRequest(name="foo", other="apple")
    String getWithFoo();

    @GET
    @CustomRequestFilter(name="bar", other="banana")
    String getWithBar();
}

[geoand]

@michalszynkiewicz perhaps this is something you could consider for the new MP Client?

[michalszynkiewicz]

It definitely cannot be @RegisterProvider - this annotation can only be used on classes (unless we change the MP spec).

In a filter you can check which method it is executed for. Would that help you @cortex93 ?

[cortex93]

It definitely cannot be @RegisterProvider - this annotation can only be used on classes (unless we change the MP spec).

In a filter you can check which method it is executed for. Would that help you @cortex93 ?

I'm not sure to understand. Would it be possible to introspect an annotation on that method ?
The use case would be :

@RegisterRestClient
@CustomRequestFilter
@Path("/")
public interface ProtectedResourceService {

    @GET
    @CustomValue(name="foo", other="apple")
    String getWithFoo();

    @GET
    @CustomValue(name="bar", other="banana")
    String getWithBar();
}

with CustomRequestFilter having access to property values of CustomValue annotation ?

[michalszynkiewicz]

I mean ClientRequestContext has a property called org.eclipse.microprofile.rest.client.invokedMethod which contains the method that the filter was invoked for. See https://download.eclipse.org/microprofile/microprofile-rest-client-1.4.1/microprofile-rest-client-1.4.1.html#_clientrequestfilter

[michalszynkiewicz]

And yes, from the java.lang.reflect.Method object passed there you should be able to read any annotations on the method.

[cortex93]

Ok, glad to see its possible at runtime. Would it be possible to think about doing something at build time ?
I saw that there is a Token Propagation extension for oidc and support for OAuth2 is planned with more features like token exchange. This would be a perfect use case as it may require to specify target scope/audience for the exchange per given method/interface.

Note that, in my use case, I may need to be able to grab the value from configuration like @CustomValue(nameConfigKey="custom.name.value") but its no big deal with reflection at runtime.

Thanks for helping

[michalszynkiewicz]

Another option is to use interceptors, but this doesn't give such an easy access to the request context.

I'm not sure how common this use case is. Let's maybe leave it open and implement it if it gets some interest in the near future?

[geoand]

I totally agree that Provider registration for the REST Client is very cumbersome and error prone so I am always in favor of making things easier (which was the motivation for #22936).

What exact use case are you looking to be addressed with this @cortex93 ?

[cortex93]

@geoand What I was trying to do to is to configure scope to request during a token exchange per method on a RestClient interface.

Currently, AccessTokenRequestFilter can use only one specific oidc client. So, while I can configure token exchange scope, it is done for all rest client interface decorated with the AccessTokenRequestFilter.

Ideally, in one application, I would like something like

@RegisterRestClient
@Path("/")
public interface ProtectedResourceA {

    @GET
    @RegisterProvider(AccessTokenRequestFilter.class)
    @TokenExchange(scope = "a:foo")
    String getWithFoo();

    @GET
    @RegisterProvider(AccessTokenRequestFilter.class)
    @TokenExchange(scope = "a:bar")
    String getWithBar();
}

@RegisterRestClient
@TokenExchange(scope = "b:all")
@Path("/")
public interface ProtectedResourceB {

    @GET
    @RegisterProvider(AccessTokenRequestFilter.class)
    String getWithFoo();

    @GET
    @RegisterProvider(AccessTokenRequestFilter.class)
    String getWithBar();
}

Eventually, it can support a @NamedOidcClient("exchange-a"). It should be like the actual config property quarkus.oidc-token-propagation.client-name but fine-grained. But IMHO, it means a lot of config to duplicate. In most common cases, there is only one OIDC server. Maybe, named client should inherit default client config (I don't if it is the actual case)

[geoand]

Thanks for the information

[michalszynkiewicz]

CC @sberyozkin in case you have some tips on parameterizing AccessTokenRequestFilter differently