WebClient vs. HttpWebRequest/HttpWebResponse

Question

It seems to me that most of what can be accomplished with HttpWebRequest/Response can also be accomplished with the WebClient class. I read somewhere that WebClient is a high-level wrapper for WebRequest/Response.
So far, I can't see anything that can be accomplished with HttpWebRequest/Response that can not be accomplished with WebClient, nor where HttpWebRequest/Response will give you more "fine-grained" control.

When should I use WebClient and when HttpWebRequest/Response? (Obviously, HttpWebRequest/Response are HTTP specific.)

If HttpWebRequest/Response are lower level then WebClient, what can I accomplish with HttpWebRequest/Response that I cannot accomplish with WebClient?

Inelegance

Answer 1

Using HttpWebRequest gives you more control on the request. You can set cookies, headers, protocol, etc... In the response, you can also retrieve the cookies and headers

Actinium

Thomas, still not convinced... WebClient has a Headers property, you can retrieve the cookie like this: String cookie = webClient.ResponseHeaders(“Set-Cookie”) and set it: webClient.Headers.Add("Cookie", "CommunityServer-UserCookie…"); – Inelegance

So you have to handle the cookies manually... not very convenient. I agree that in most cases, WebClient is OK, and actually better than HttpWebRequest because it's simpler to use, but in some cases you're better off using HttpWebRequest – Actinium

Using HttpWebRequest you can define a timeout. In WebClient, that's impossible. – Delphina

@ripper234, actually it is possible: you just have to inherit WebClient and override GetWebRequest to customize the HttpWebRequest – Actinium

Hmm, interesting - I never thought of that! – Delphina

@ThomasLevesque if you are inheriting webclient and overriding the webrequest, it seems pointless to use the webclient... – Dekker

@HagaiL, I disagree... You don't have to create the whole request manually, you can use base.GetWebRequest to create it and then customize just what you want – Actinium

Answer 2

HttpWebRequest exposes a lot more stuff that allows you fine grained protocol control, for eg: whether you want to use Keep-Alive, what connection pool to use, whether to buffer writes or not, etc.

WebClient does not expose all of those (although you can subclass from WebClient and getaccess to the underlying Request object).

WebClient is useful for those situations where you just want to do an operation (eg: POST/GET/Form upload) and cant be bothered to create and manage the HttpWebRequest, RequestStream, HttpWebResponse, and response stream.

Ebert

Also, there is one more thing that I forgot to mention. WebClient is a Component object, whereas HttpWebRequest is not. What does that mean? Well, if you are using VisualStudio to build a GUI app, then you can drag/drop WebClient component on your form and use it to issue requests to HTTP/FTP etc servers. – Ebert

Answer 3

From Tim Heuer's blog - http://timheuer.com/blog/archive/2008/03/14/calling-web-services-with-silverlight-2.aspx

Instead in Silverlight you'll want to use WebClient or HttpWebRequest. What's the difference? Here's the timheuer version. WebClient is a simpler implementation doing GET requests really easily and get a response stream. HttpWebRequest is great for when you need a bit more granular control over the request, need to send headers or other customizations.

Goings

WebClient also allows POST, with UploadString, UploadData and UploadFile – Actinium

@ThomasLevesque Is there a newer version of the classes today? I see that this discussion is a bit, hmm... aged... – Unbeatable

@KonradViltersten, I don't think there's been much change to the WebClient class. For new apps I suggest you use HttpClient instead, which is also very easy to use and much more flexible. – Actinium

@ThomasLevesque Right, that was the one I was thinking about. I recalled http as the difference in the class name and got mislead by Http... part. Now I'm back on the right track. Thanks! – Unbeatable

Answer 4

The WebClient class runs on the user interface thread, so the user interface is not responsive while data is being downloaded from the Internet. On the other hand, the HttpWebRequest class does not block the user interface thread, and your application is responsive. So, in apps where a large amount of data is to be downloaded from the Internet or if the source of the data is slow to access, you should use the HttpWebRequest class; in all other cases, you should use the WebClient class.

Tarryn

The opposite is true on WP7. HttpWebRequest marshals back to the UI thread in Mango, causing me no end of grief right now. Grrr – Justiciary

WebClient supports asynchronous methods as well. – Deena

Answer 5

Another disadvantage of WebClient is it ignores the HTTP ContentType's charset value when you use it to get the response text. You have to explicitly set the encoding via the Encoding property.

Funest

This is a good point; and it's not just a matter of setting the Encoding - you can't know the encoding until after the request, so the WebClient api makes it very unlikely you're going to be able to properly download a string in an unknown encoding. – Powers

Answer 6

One more thing HttpWebrquest allows you compression but he Net.WebClient class doesn't support HTTP compression

Farseeing

Just like all the other examples of WebClient hiding some details, this can be fixed by subclassing WebClient and overriding GetWebRequest. In this case, you simply tweak the underlying HttpWebRequest.AutomaticDecompressiong property). – Leanora

Answer 7

The "HtttpWebRequest" is obsolete in .NET 4.5. Now, this class is internal only.

Plimsoll

Indeed. Use WebRequest instead. – Abagail

The class is not obsolete, the constructors are. And the class is not internal, it is still public. – Disembogue

Answer 8

One example: Posting data and getting back processed data in one request/response cycle seems to be impossible with WebClient, but you can do that with HtttpWebRequest.

Treponema

Simply use WebClient.UploadString or WebClient.UploadData to perform a POST and get back a response string or byte array. – Lillianalillie

To clarify, the return value of the UploadString is a string and the return value of the UploadData method is a byte array. – Appetizer