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?

Solution 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

Solution 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.

Solution 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.

Solution 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.

Solution 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.

View more solutions

Comments

[Thomas Levesque]

WebClient also allows POST, with UploadString, UploadData and UploadFile

[Dan]

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…");

[Thomas Levesque]

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

[feroze]

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.

[ripper234]

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

[Thomas Levesque]

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

[ripper234]

Hmm, interesting - I never thought of that!

[samjudson]

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

[Norman H]

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

[Cameron MacFarland]

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

[Hagai L]

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

[Thomas Levesque]

@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

[patridge]

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).

[CyberMonk]

WebClient supports asynchronous methods as well.

[silkfire]

Indeed. Use WebRequest instead.

[Eamon Nerbonne]

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.

[Konrad Viltersten]

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

[Thomas Levesque]

@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.

[Konrad Viltersten]

@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!

[user247702]

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