In my scenario, I have to send data from one web application to a webapi which is an effective data store. The requests are necessarily synchronous and I most definitely want an Exception
thrown if something goes awry as it means a critical part of the application is unavailable.
This is a derivative of, though not duplication of an existing question; Why use HttpClient for Synchronous Connection.
Yet over and over, including in the article I see above, I see a consistent recommendation to use HttpClient
, even in a synchronous scenario. The best reason I've seen is the accepted answer in the SO post above but it essentially boils down to;
Use this because "shiny".
Which I'm not liking as an acceptable answer for my scenario. I'd prefer to use the correct object for the task at hand and this seems to be the older HttpWebRequest
. Even Ben Watson's excellent resource "Writing High-Performance .NET Code" states the following;
Another example is the
System.Net.HttpWebRequest
class, which will throw an exception if it receives a non-200 response from a server. This bizarre behavior is thankfully corrected in theSystem.Net.Http.HttpClient
class in .NET 4.5
But in my scenario, I actually do want that behavior. While there are a lot of good use cases for HttpClient
, can anyone offer a good reason not to use HttpWebRequest
in my scenario? Am I using the correct object or not? And more importantly, why?
HttpClient
is designed to give more control over http protocol, where else doing same in HttpWebRequest
or WebClient
was not that straight forward. Apart from asynchronous, there are many benefits of HttpClient
Benefits of HttpClient
Biggest benefit of HttpClient
is plugin architecture, that lets you change underlying behavior of HTTP protocol easily.
HttpClient
is extensible, underlying HttpMessageHandler
allows you to completely by pass underlying Microsoft's HttpClient implementation and you can plugin your own implementation. For example, in iOS and Android, instead of using .Net's HttpClient, we could use native Http stack.HttpMessageHandler
CancellationToken
support is excellent when we want to cancel a long running Http request. HttpClient
is optimized to manage multiple requests with single instance. CPU time is utilized very efficiently without using too many locks (synchronous operations depend on locks, which is considerable overhead on CPU). Today we are living in world of micro services. In server with many clients to serve and mobile OS, CPU time is costly.Drawbacks
Only drawback is async/await
, you can't simply use async libraries easily in synchronous code without using a Task Runner or deadlocks. Though there are many libraries supporting how to synchronously use async code.
There is no great benefit of HttpClient
on Desktop application with lots of CPU time as spare.