CSharp - IHttpClientFactory

[kimbell]

For years I've been using NSwag for generating typed clients from OpenApi documents. When I discovered Kiota, it became an interesting possibility that needs a bit more investigation. The NSwag code takes in an HttpClient and is only responsible for the actual network serialization/deserialization. Kiota seems to be adding a bunch of other concepts on top such as authentication, retries, etc. There is also a KiotaClientFactory for creating HttpClients.

Microsoft made an investment in the IHttpClientFactory system as part of ASP.NET Core; and I love it. How does that fit in with Kiota? In Kiota it seems that everything is baked into the client. With IHttpClientFactory approach, things are more split. You can create one client and potentially secure it using different mechanisms depending on your environment; full Azure AD in production, something else on local dev box.

[baywet]

Hi Christopher,
Thanks for reaching out and for your interest in Kiota.
One aspect that is briefly mentioned in our docs but could be expanded (CC @jasonjoh) is the fact that the generated code doesn't "force" any implementation for three aspects:

• authentication (scheme, library...)
• serialization (format, library)
• http "translation" (library)

When you generate a client, it only depends on Kiota abstractions to build, this abstractions library defines a set of interfaces that need to be implemented so the code can run.
We (Microsoft) provide a set of default extensions, and you're more than welcome to use them, roll up your own implementation, or rely on a third party community one.

If we focus on the http adapter implementation for dotnet, it relies on http client, and can either instantiate one itself or accept one as a parameter.
Adding the ASP.NET Core client factory in this context, you could perfectly:

1. Generate a client
2. Add http client to the services
3. Add the generated client in the service injection using the add transient method, in combination with the GetDefaultHttpMessageHanlder method from the kiota factory (and customize that all the way you want.
4. In the same AddTransient callback used to inject the http client, you can also configure things like serialization/deserialization providers, and authentication, by reading the configuration or not, for the generated client.

I hope that clarifies this aspect, let us know if you have further questions.

[olandese]

it would be nice to have an example how to deal in C# with DI and a Kiota generated client

[baywet]

That's a good point @jasonjoh can you create an issue in the docs repo for this please?

[jasonjoh]

Done.

[madhon]

Where's the docs repo to track this issue ? s far as i can see there's nothing about this in the docs on ms learn

[baywet]

Https://GitHub.com/Microsoftdocs/openapi-docs

[kimbell]

When I first started digging into this, I thought it would rather tricky since you get a bit blinded by all the abstractions Kiota adds with numerous builders and providers. It turned out to be a lot simpler than I thought.

For our use-case, we handle authentication and other things via delegating handlers that are added to the HttpClient setup. We are only looking for a strongly typed client that wraps an HttpClient that we provide via IHttpClientFactory.

This is what I created for my testing; the key is that HttpClientRequestAdapter can take an external HttpClient.
In the sample code below TypeClient is the client generated by the Kiota tooling.

public interface IExternalClient
{
    Task<IEnumerable<Models.WeatherForecast>?> GetForecastAsync();
}

public class ExternalClient : IExternalClient
{
    private readonly IAuthenticationProvider _authProvider = new AnonymousAuthenticationProvider();
    private readonly TypeClient _client;

    public ExternalClient(HttpClient httpClient)
    {
        var adapter = new HttpClientRequestAdapter(_authProvider, httpClient: httpClient);
        _client = new TypeClient(adapter);
    }

    public async Task<IEnumerable<Models.WeatherForecast>?> GetForecastAsync()
    {
        return await _client.WeatherForecast.Weather.GetAsync();
    }
}

Our custom client can then be set up like any other that uses the IHttpClientFactory infrastructure.

 services
     .AddHttpClient("Bob")
     .AddTypedClient<IExternalClient>(httpClient => new ExternalClient(httpClient))
     .ConfigureHttpClient(httpClient => httpClient.BaseAddress = new Uri("http://something"));

[drdamour]

@kimbell what's the significance of the AddHttpclient("Bob") in your example? is it an idiom you use to get to the IHttpClientBuilder you're after (so you can setup the factory with AddTypedClient)?

[kimbell]

It's just a name to set up a named HttpClient. Since configuration is done based on name, we can set up things in our program.cs for normal application usage. For tests we use the WebApplicationFactory system; in that context we may want to change the primary message handler or add additional delegating handlers; using deterministic names allows us to do that.

[kimbell]

It's both; a named client and a typed client. AddHttpClient() returns an IHttpClientBuilder; this builder gives you AddTypedClient(). For application usage, you can use the typed client. For setup, you can use the named client.

[drdamour]

@kimbell i'm pretty sure it's two separate clients. Typed clients are just fancy named clients behind the scenes. If you call CreateClient("bob") i think you'll find that the base address is NOT set to http://something

[kimbell]

The documentation for AddTypedClient() states
Configures a binding between the TClient type and the named HttpClient associated with the IHttpClientBuilder
so you need a named client (explicit or default named) before you can add a typed client.

In my testing repo for Kiota, I added an additional test to verify that the BaseAddress from both typed and named client are the same.
https://github.com/kimbell/Kiota.Testing/blob/36b60a0fb1dcd70e52fa8bd3a555cfec5800e9ca/Bob.Kiota.Tests/GeneralTests.cs#L23

[drdamour]

@kimbell hm...i def stand corrected, thanks for correcting me

so you need a named client (explicit or default named) before you can add a typed client.

I've always used services.AddHttpClient() to do this (which creates a named client based on ITypedClient's type name) and always thought AddTypedClient did the same.

my eyes are open, thx again!

[kimbell]

I've found the named client setup incredibly useful; you can call AddHttpClient() multiple times with the same name, and things get combined.

I have the application set things up based on it's needs. For tests, I then have the option to add a DelegatingHandler that can intercept and modify data before it's sent out of the application. In some cases I can return 100% mocked data, in other cases I can combine real data with mocked data. All this code only has an impact on the test; so there is no risk when the application is running normally.

With the old WCF clients, the HttpClient was buried deep in the code somewhere resulting in you having to structure your code so that it could be tested; i.e. by wrapping a small part of it in an interface. The new HttpClient stuff has all this built-in.