In your RestHelper, you use a shared instance of the HttpClient for sending the requests. This way we won't have the problem with the socket exhaustion since the instance is only one and it is reused but this can lead to another problem with not respecting DNS changes. The only way to apply the DNS changes to the client is by restarting the application so that the HttpClient instance is created again. This can be resolved if you use IHttpClientFactory. What is more, many articles and Microsoft docs recommend using the IHttpClientFactory for retrieving new HttpClient instances, coping with socket exhaustion problems, and the DNS one as well. Moreover, the IHttpClientFactory brings many optimizations in the performance and reliability of the HttpClient.
For reference:
'You're (probably still) using HttpClient wrong and it is destabilizing your software', Josef Ottosson - link - you can check the section with the benchmarks and see that IHttpClientFactory is much better in performance than the HttpClient itself.
'Pool HTTP connections with HttpClientFactory', ASP.NET Core Performance Best Practices - link
'HTTPCLIENT CREATION AND DISPOSAL INTERNALS: SHOULD I DISPOSE OF HTTPCLIENT?', Steve Gordon - link
In your RestHelper, you use a shared instance of the HttpClient for sending the requests. This way we won't have the problem with the socket exhaustion since the instance is only one and it is reused but this can lead to another problem with not respecting DNS changes. The only way to apply the DNS changes to the client is by restarting the application so that the HttpClient instance is created again. This can be resolved if you use IHttpClientFactory. What is more, many articles and Microsoft docs recommend using the IHttpClientFactory for retrieving new HttpClient instances, coping with socket exhaustion problems, and the DNS one as well. Moreover, the IHttpClientFactory brings many optimizations in the performance and reliability of the HttpClient. For reference: