.Net Core HttpClientFactory dla wielu usług interfejsu API

Question

Mam projekt .Net Core, który musi łączyć się z około 4 różnymi usługami API, nie jestem ekspertem w żadnym z kodów HttpClient, ale z tego, co odkryłem, wynika, że ​​generalnie chcesz ponownie użyć tylko jednego wystąpienia Twojego HttpClient. Z tego, co mogę powiedzieć, ogólny konsensus jest taki, aby użyć HttpClientFactory w .Net Core, rejestrując go w swojej klasie Startup, a następnie żądając go za pomocą DI.

Teraz większość moich domyślnych nagłówków i takie są ogólnie takie same, poza adresem URL BaseAddress, jak mam to zrobić, łącząc się z usługami API 4 diff? Czy powinienem zarejestrować 4 różnych nazwanych klientów, czy też mieć jednego klienta z wstępnie ustawionymi wszystkimi domyślnymi informacjami, a następnie ręcznie skonfigurować go w razie potrzeby, np. Konfigurując adres?

Ogólne pytania byłyby, ponieważ jestem całkiem nowy w tym, mówi się, że ponownie używa jednego wystąpienia HttpClient.

1. Jeśli utworzę 4 różnych nazwanych klientów dla każdej usługi API, czy nie spowoduje to utworzenia 4 wystąpień HttpClient podczas wywoływania metody .CreateClient ()?
2. .CreateClient () tworzy nowe wystąpienie za każdym razem, gdy jest wywoływane, czy nie jest to sprzeczne z celem posiadania jednego wystąpienia HttpClient, jeśli mówię, że muszę wykonać 3 różne wywołania jednej usługi API, każde z tych wywołań wywoła plik. CreateClient () w celu ustanowienia jakiegoś połączenia, które utworzy 3 wystąpienia HttpClient?

Każda pomoc dla jasności będzie mile widziana,

Dzięki!

Answer 1

Celem użycia IHttpClientFactorynie jest ponowne użycie wystąpień HttpClient. Zamiast tego, jest to ponowne wykorzystanie (poprzez łączenie) wystąpień HttpMessageHandler(w rzeczywistości HttpClientHandler, który jest wyprowadzony z abstraktu HttpMessageHandler), który jest podstawowym obiektem, który zarządza połączeniami i gniazdami HTTP. Ten diagram z Microsoft Docs dobrze to pokazuje.

Martwiłeś się, że częste połączenia z numerem IHttpClientFactory.CreateClient()spowodują ten sam problem, co częste połączenia z numerem new HttpClient(). Jednak tak nie jest. Jak wyjaśniono w Microsoft Docs , powodem, dla którego częste wywołania do new HttpClient()skutkują wyczerpaniem gniazda, jest to, że ten konstruktor utworzy nową instancję HttpMessageHandler:

Jednak problem nie jest tak naprawdę z HttpClient jako takim, ale z domyślnym konstruktorem dla HttpClient, ponieważ tworzy nowe konkretne wystąpienie HttpMessageHandler, które ma wyczerpanie gniazd i problemy ze zmianami DNS wymienione powyżej.

Można zobaczyć z kodem źródłowym na IHttpClientFactoryto, że nie używa konstruktora bez parametrów z HttpClientw CreateClient(). Zamiast tego pobiera HttpMessageHandlerz puli i wstrzykuje go do utworzonego HttpClient.

Niezależnie od tego, czy używasz klientów wpisanych, czy nazwanych, powinieneś używać wystąpienia HttpClient tak, jakby był to obiekt przejściowy: jest tani w tworzeniu i nie ma potrzeby buforowania go przez długi czas.