In Microsoft's documentation, in the Named Clients example, they retrieve an HttpClient from the IoC container:

var httpClient = _httpClientFactory.CreateClient("GitHub");

In the Typed Clients example, the service that they register as an HttpClient, GitHubService, creates its own HttpClient:

public class GitHubService
    private readonly HttpClient _httpClient;

    public GitHubService(HttpClient httpClient)
        _httpClient = httpClient;

Then, of course, to use the HttpClient, a consuming class would create an instance of GitHubService.

This leaves me with two questions:

  1. In the Typed Clients example, is GitHubService actually implementing IHttpClientFactory since it is creating its HttpClient directly?
  2. Also in the Typed Clients example, what role is the IoC container playing? Couldn't the same be done without registering GitHubService with the IoC container at all?
  • If GitHubService implemented IHttpClientFactory, then you would see this code: public class GitHubService : IHttpClientFactory Aug 26, 2022 at 17:27
  • "GitHubService, creates its own HttpClient" - I think this is at the root of your confusion. GitHubService does not create an HttpClient - go through the article, you'll see that this isn't stated anywhere. The HttpClient is externally injected, and GitHubService just stores whatever instance was provided to it. You also say "to use the HttpClient, a consuming class would create an instance of GitHubService", but it's exactly the other way around - for calling code to use a GitHubService instance, it has to either create an HttpClient first, then pass it to GitHubService constructor, or 1/2 Aug 26, 2022 at 19:02
  • ...or it has to receive a GitHubService instance from some other code that already has it or knows how to make one (in this case, the DI container). [for clarity: talking about the Typed Client example] 2/2 Aug 26, 2022 at 19:02
  • @FilipMilovanović thanks for your response. You're right about the HttpClient in GitHubService; I should re-word that. However, when a new instance of GitHubService is instantiated, doesn't the caller have to provide an HttpClient? Otherwise, the caller does not meet the requirements of GitHubService's constructor, no?
    – chrisxfire
    Aug 26, 2022 at 19:11
  • Yes - that's what I wrote above. Whatever code is directly creating the GitHubService instance (and this code is not necessarily the intended client code), it has to provide an HttpClient. In the case where the caller is also the one creating the GitHubService, providing an HttpClient is also its responsibility. Otherwise, some other code does that work (instantiation), and provides the HttpClient to the GitHubService constructor - and this is the role that the IoC container plays. Aug 26, 2022 at 19:26

1 Answer 1


The key thing you are missing from the Typed Client example is the way it is instantiated

"The typed client is registered as transient with DI"

This means every time it's fetched from the DI container, the DI container creates a new instance. The new instance needs a new httpClient for its construction, which is in turn provided by the DI container via a registered HttpClientFactory.

So to answer your direct questions

  1. No, it doesn't create and expose a httpClient.

  2. The role of the IoC container is to ensure that the httpClient used is generated from the client factory every time GitHubService.GetAspNetCoreDocsBranchesAsync() is called.

    If you didn't use the container then you would have to manage the lifecycle of the underlying HttpClient yourself.

I'm guessing this example is provided to give you guidance on how to integrate this popular way of writing a service class which takes a httpCient as a construction parameter rather than a IHttpClientFactory

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.