Has anything been written about why we might want to use UnityWebRequest over .NET’s own HttpWebRequest (other than the WebGL consideration)?
There doesn’t seem to be a lot of information out there about it even though it’s slated to no longer be “experimental” in 5.4.
I’m about to start writing a huge number of REST calls and a custom server to process them. I’m deeply familiar with WebRequest and HttpWebRequest but the general lack of concrete information about UnityWebRequest makes me a bit nervous. (For example, it feels like a warning sign that someone would write an HTTP class with a property named URL instead of URI… although to be fair, even MSDN mixes them up pretty regularly.)
Both will probably get you what you need (make HTTP REST calls to a web server to fetch / update data).
The .NET APIs are probably more mature, on the other hand when using them, you are forced to use the larger set of .NET libraries so stripping will be less efficient.
UnityWebRequest is a managed (C#) wrapper API around a set of native functions that the engine runs. As such, it can probably (and it IS probably) optimized to conserve memory, etc. Also, it works together with Unity’s paradigms (coroutines, etc).
Thanks. The stripping angle hadn’t occurred to me. Does stripping happen on all platform release builds? I thought it was just iOS and WebGL, but now I realize I don’t know for certain.
Apart from that I’ve made the same assumptions, but it would be nice to hear something from Unity themselves.
Well, i think it can have an effect on other platforms as well.
You have this setting in the player settings:
Using the “subset” means you don’t have access to many classes (i think HttpWebRequest may be one of them).
Selecting the other one brings in a bunch of other classes that will probably bloat your game and increase the install size.
Ah, thanks – found a list from a thread you created last year! Looks like System.Net and HttpWebRequest is part of the 2.0 subset. Or was in 4.x anyway. I thought stripping was automatic based on what was actually used. I’ll probably try UnityWebRequest anyway though.
ArgumentException: Cannot set a Request header with a null or empty value
Edit: Here’s irony for you, from the useHttpContinue API page: “If this property is set to true, then this UnityWebRequest will include an Expect: 100-Continue header in the initial outbound request. If set to false, an empty Expect header will be sent, which will suppress usage of the 100 Continue response code.”
