.Net Core HttpClientFactory pour plusieurs services d'API

Question

J'ai un projet .Net Core qui doit se connecter à environ 4 services d'API différents, je ne suis pas un expert du code HttpClient, mais d'après ce que j'ai trouvé, vous ne voudriez généralement réutiliser qu'une seule instance de votre HttpClient. D'après ce que je peux dire, le consensus général est d'utiliser HttpClientFactory dans .Net Core en l'enregistrant dans votre classe de démarrage, puis en le demandant à l'aide de DI.

Maintenant, la plupart de mes en-têtes par défaut et autres sont généralement les mêmes en plus de l'URL BaseAddress, comment dois-je procéder lorsque je me connecte à 4 services API diff? Dois-je enregistrer 4 clients nommés différents ou avoir un client avec toutes les informations par défaut prédéfinies, puis le configurer manuellement si nécessaire, par exemple en configurant l'adresse?

Les questions générales seraient, car je suis assez nouveau dans ce domaine, il a été dit de réutiliser une instance d'un HttpClient.

1. Si je crée 4 clients nommés différents pour chaque service d'API, cela ne créerait-il pas 4 instances de HttpClient lorsque j'appelle la méthode .CreateClient ()?
2. Le .CreateClient () crée une nouvelle instance à chaque fois qu'il est appelé, cela ne va-t-il pas à l'encontre de l'objectif d'avoir une instance du HttpClient si je dois faire 3 appels différents à un service API, chacun de ces appels appellera un. CreateClient () pour établir une sorte de connexion et qui créera 3 instances du HttpClient?

Toute aide pour plus de clarté serait appréciée,

Merci!

Answer 1

Le but de l'utilisation IHttpClientFactoryn'est pas de réutiliser des instances de HttpClient. Au lieu de cela, il s'agit de réutiliser (en regroupant) les instances de HttpMessageHandler(en fait HttpClientHandler, qui est dérivé de l'abstrait HttpMessageHandler) qui est l'objet sous-jacent qui gère les connexions HTTP et les sockets. Ce diagramme de Microsoft Docs le montre bien.

Vous craigniez que les appels fréquents vers IHttpClientFactory.CreateClient()ne créent le même problème que les appels fréquents vers new HttpClient(). Cependant, ce n'est pas le cas. Comme expliqué par Microsoft docs , la raison pour laquelle les appels fréquents à new HttpClient()entraîneront l'épuisement des sockets est que ce constructeur créera une nouvelle instance de HttpMessageHandler:

Cependant, le problème n'est pas vraiment avec HttpClient en soi, mais avec le constructeur par défaut pour HttpClient, car il crée une nouvelle instance concrète de HttpMessageHandler, qui est celle qui a des problèmes d'épuisement des sockets et de changements DNS mentionnés ci-dessus.

Vous pouvez voir à partir du code source de IHttpClientFactoryce qu'il n'utilise pas le constructeur de parameterless HttpClientdans CreateClient(). Au lieu de cela, il récupère le HttpMessageHandlerdepuis un pool et l'injecte dans le fichier créé HttpClient.

Que vous utilisiez des clients typés ou nommés, vous devez utiliser l'instance HttpClient comme s'il s'agissait d'un objet transitoire: sa création est peu coûteuse et vous n'avez pas besoin de la mettre en cache pendant de longues périodes.