[API Proposal]: Consider adding methods to the HTTP Client factory that receive Type parameters instead of generic type parameters

[paulomorgado]

Updated by @CarnaViire

API:

namespace Microsoft.Extensions.DependencyInjection;

public static class HttpClientBuilderExtensions
{
    public static IHttpClientBuilder AddTypedClient(
        this IHttpClientBuilder builder,
        Type clientType,
        Type? ImplementationType = null);
}

Usage:

services.AddHttpClient(name)
    .AddTypedClient(clientType, clientImplementationType);

---

Original issue by @paulomorgado

Background and motivation

Sometimes I have the need to register HTTP clients from configuration files and, for that, I need to construct a generic method for each type.

API Proposal

namespace Microsoft.Extensions.DependencyInjection;

public static class HttpClientFactoryServiceCollectionExtensions
{
    public static IHttpClientBuilder AddHttpClient(
        this IServiceCollection services,
        Type clientType,
        Type ImplementationType);
}

API Usage

service.AddHttpClient(clientType, implementationType);

Alternative Designs

No response

Risks

There might be a risk for overloads with factory methods, as correctness might be hard to guarantee.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[julealgon]

Sometimes I have the need to register HTTP clients from configuration files...

Would you mind sharing an example of what you are doing?

I fail to see why you are not using named (but untyped) HTTP client registrations and using IHttpClientFactory explicitly with a dynamic setup. No need to call that overload you are proposing then: you just register the various HttpClients separately.

[paulomorgado]

@julealgon,

Sometimes I have the need to register HTTP clients from configuration files...

Would you mind sharing an example of what you are doing?

I fail to see why you are not using named (but untyped) HTTP client registrations and using IHttpClientFactory explicitly with a dynamic setup. No need to call that overload you are proposing then: you just register the various HttpClients separately.

Instead of explicitly registering the HTTP clients in code, I use configuration for that.

At startup, I add all the HTTP clients in the configuration. And the configuration might have type HTTP clients.

[julealgon]

@paulomorgado I think you misunderstood what I asked. I 100% understand that you are dynamically registering the clients based on configuration, but my point specifically was that you don't need to use the typed registration methods to achieve that, you can just used named registrations instead and then inject IHttpClientFactory into your consumers and grab the named client from that.

If you know how WCF config-based bindings worked in the past, this would be very similar to that.

[paulomorgado]

@julealgon,

@paulomorgado I think you misunderstood what I asked. I 100% understand that you are dynamically registering the clients based on configuration, but my point specifically was that you don't need to use the typed registration methods to achieve that, you can just used named registrations instead and then inject IHttpClientFactory into your consumers and grab the named client from that.

If you know how WCF config-based bindings worked in the past, this would be very similar to that.

I know I can do that, but my components have the typed clients injected and I never inject the IHttpClientFactory.

Just because I can inject IHttpClientFactory, doesn't mean I should.

[julealgon]

I know I can do that, but my components have the typed clients injected and I never inject the IHttpClientFactory.

Just because I can inject IHttpClientFactory, doesn't mean I should.

Fair enough. I was just checking whether the named registrations could be a way for your use case: looks like it isn't.

Would still be nice if you could share a sample of your problem to make a stronger case for the proposed API.

In the meantime, you could just register the types yourself using ActivatorUtilities:

services.AddHttpClient(myHttpClientName, //...configure here...
services.AddTransient(myInterface, provider => ActivatorUtilities.CreateInstance(
    provider, 
    myType, 
    provider.GetRequiredService<IHttpClientFactory>().CreateClient(myHttpClientName))

Which you could, of course, abstract away into your own generic helper method.

The problem I see with the original AddHttpClient<T> methods is that they.... don't scale as an API: eventually, people will request for every single variation that exists for other Add... methods, and I'm personally not that fond of that design: I'd rather see it die in favor of a general purpose "dependent" registration feature. But alas.

[paulomorgado]

I have a working solution. I just don't think this is my requirement only and the factory usability would benefit from this.

[julealgon]

I have a working solution.

Again, I would suggest sharing your use case and your current workaround so more people can see the benefit of the new API and can rely on your workaround in the meantime.

I just don't think this is my requirement only and the factory usability would benefit from this.

I've never seen anyone else request this myself. All dynamic registration discussions revolved around named httpclient registrations or even using the new keyed registration support.

[paulomorgado]

I am dynamically registering typed HTTP clients.

The particulars of why I need to do it are not important nor I will discuss them publicly.

[CarnaViire]

Thanks for the proposal @paulomorgado

Triage:

There are already 20 (!) overloads of AddHttpClient. We are extremely reluctant to expand this even further, as it will hurt the usability more than it will help. Given that there are working solutions for the problem described (incl. the workarounds proposed above, thanks @julealgon), and there is not much customer ask for that (this is the first one that I'm aware of), we're inclined towards closing the issue.

Please let me know if I missed something, or there's some additional reasons why we should reconsider. Thanks!