System.Net.Http.HttpClient vs Windows.Web.Http.HttpClient - What are the main differences?

Question

When developing .NET 4.5 desktop apps for Windows I have been used to use System.Net.Http.HttpClient for all communication with a backend Web API. I am now developing a Windows Store app and has noticed the existence of Windows.Web.Http.HttpClient. I have looked for information on what the main differences are between the two clients but without any luck.

From MSDN I know that I should start using Windows.Web.Http.HttpClient in my Windows Store app since System.Net.Http.HttpClient might be removed from the API:

Note The System.Net.Http and System.Net.Http.Headers namespace might not be available in future versions of Windows for use by Windows Store apps. Starting with Windows 8.1 and Windows Server 2012 R2, use Windows.Web.Http.HttpClient in the Windows.Web.Http namespace and the related Windows.Web.Http.Headers and Windows.Web.Http.Filters namespaces instead for Windows Runtime apps.

But apart from this information, I have a hard time figuring out what are the main differences and what is the main benefit of using Windows.Web.Http.HttpClient? What does it add that we don't already got in System.Net.Http.HttpClient?

Answers backed by official documentation are greatly appreciated.

Solution 1

There is not much to find about it. Some things that come in my mind:

• The new API doesn't have dependencies to some low-level Windows functions, like the current API does.
• The new API is better capable handling new methods related to the HTTP protocol, like WebSockets, etc.

Some useful information can be found in this blog post which also referenced this Build video. They speak about better cache control, and a way to add filters for authentication, easy access to cookies, reconnecting, etc.

Solution 2

Windows.Web.Http is a WinRT API available in all the WinRT programming languages supported: C#, VB, C++/CX and JavaScript. This enables the option to write the same code in the language of your choice.

System.Net.Http is a .NET API, and it is only available for C# and VB developers.

Windows.Web.Http advantages

• WinRT APIs are written in native code, which translates in better performance.
• Windows.Web.Http is on top of a common Windows HTTP stack, and reuses resources already in use by other Windows components. System.Net.Http is a separate implementation of the HTTP protocol that is not frequently used by other Windows components. So, in some cases, you save resources by choosing Windows.Web.Http.
• Windows.Web.Http has better integration with WinRT types, such as IInputStream, IOutputStream and IBuffer. Avoiding the .NET extensions that convert System.IO.Stream into IInputStream or IOutputStream and System.Array into Windows.Storage.Streams.IBuffer can improve performance and save resources in some cases.
• Windows.Web.Http has the new features, such as HTTP/2 support.
• Windows.Web.Http is COM based and can be used by any programming language that understands COM.

System.Net.Http advantages

• System.Net.Http is available since Windows 8 or .NET 4.5 and Windows.Web.Http is only available since Windows 8.1 and Windows Phone 8.1.
• It is straight forward to port WinRT code using System.Net.Http to ASP.NET or Xamarin (Portable Class Library)
• Windows 8 and 8.1 projects or desktop projects: †
  • Authentication headers and credentials are isolated per HttpClient (example)
  • Cookie container isolated per HttpClient
  • Does not cache HTTP responses, so subsequent requests will never come from the cache, a common issue with servers that does not set the correct Cache-Control header (example)
  • Works with System.Net.NetworkCredential

† For Windows Universal Projects (UWP), System.Net.Http is a wrapper on top of Windows.Web.Http, as described here.

Further reading: Demystifying HttpClient APIs in the Universal Windows Platform

Comments

[Lasse Christiansen]

This makes perfect sense. Thanks for sharing your thoughts. I have seen parts of the Build video as well and I have to admit, that I cannot understand how MS can spend time hyping this new client and then not provide details on how it differs from the existing System.Net.Http.HttpClient and how to use this set of new features. But anyway, thanks again.