Difference between HttpClient and Unity's Unit

Question

Unity now supports .NET 4.5 and I'm able to use the HttpClient class from the System.Net.Http namespace. That is great since I have existing client libraries which are therefore easy to reuse.

Does anyone know the internal difference between using the mono HttpClient and Unity's own networking classes?

I'm afraid that the HttpClient is not as optimized for the different platforms and might therefore cause trouble or be slower.

Answer 1

There are many differences between the two.

• UnityWebRequest won't allow you to use change some headers. With HttpClient, you can change almost any header.

• UnityWebRequest is made to be used without worrying about threads or async stuff. All you do is use coroutine to wait for the request. The whole thread stuff is already done for you on the native side.

• Some platforms don't support anything from the System.Net namespace. One of this is WebGL. This means that HttpClient will not even compile when you switch your platform to WebGL. UnityWebRequest works fine with WebGL.

• UnityWebRequest is made to make it easier to download data in memory and convert the data into Unity resources such as AudioClip, VideoClip, AssetBundle, Texture2D and more. With HttpClient, you will have to write lots of codes just retrieve such data or probably have to save the data on the disc after receiving them just to be able to convert them into Unity resources form.

• Want to use SSL with UnityWebRequest? Good luck with that! You will only end up with the ambiguous "unknown error" error. When SSL is involved in your HttpClient is the option.

With everything I just mentioned, you should port your code to use UnityWebRequest unless you are doing something that's not supported with UnityWebRequest.