HttpClient is not just another framework class that you can initialize and get going with it. It deserves the required attention to detail. Otherwise, it'll bite you hard and will make you read every single blog, stackoverflow post about itself. Besides this, there will be a ton of google searches. Yeah, you can't jump the queue.
Another reason why it's a storm waiting to happen for you - it has a design flaw. There was no need to implement IDisposable on it. Microsoft could have made it singleton.
There are already two great blog posts on it so I'm not going to duplicate the content. You can refer them here and here.
Alright! What are the prerequisites?
1. You should know very well about TCP\IP protocol.
But why? You might question back. Otherwise, how are you going to find out what's wrong? in case, you run into problems. The devil is in the details. It's a disconnected protocol. It will keep the ports open (default - 4 mins), due to time_wait state, even if you have disposed the httpclient object, as packets might arrive late from the host. TCP protocol has a lot of states. While in time_wait state, client machine awaits for an acknowledgement from the host to close the connection, so it keeps the ports open for a while.
Following diagram showing all the TCP/IP states cycle from communication between client and server.
2. Use only single instance of HttpClient
One of the most expensive exercises of HttpClient is the creation of its connection pool. So, while you are creating new instances, you are just adding to the cost. It's better to use your favorite DI container to make it singleton.
3. Learn about ServicePoint and ServicePointManager
These classes represent the connection pool that HttpClient uses to connect to requested urls. There are a lot of properties in these classes that you can configure according to your requirements.
I can't possibly list down every scenario that you'll come across while using HttpClient, I will list down few so that you have some starting points in case you run into any problem -
1. Try to leverage caching to cut down on cpu cycles and external requests. Benefit - lesser use of HttpClient.
2. Make you sure know the differences between all of your environments - dev, qa, uat, staging and prod
3. Try to compare IIS logs across different environments to find out the subtle differences
4. Use netstat, port monitor or build a test application to quickly simulate various scenarios and evaluate the results
We had a very serious outage at work during this past week. We quickly made the HttpClient singleton to stop port exhaustion. Applications have certainly started performing better but ports were still getting exhausted, albeit rather slowly. After, more triage, we found out - our new http services in higher environments were using different authentication mechanism. So, a small change restored the outage. This actually happened in another team so I got all of this info while debugging this problem.
There is no security risk with using UnsafeAuthenticatedConnectionSharing. If you decide to use it then please carry out your own security risk assessment.
In case, you are starting with a brand new rest api then please start with .net core. This is the future. And, it does not have any of the problems associated with classic .net framework's httpclient.
More references -