views:

1770

answers:

5

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?

+7  A: 

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

Thomas Levesque
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…");
Dan
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
Thomas Levesque
+3  A: 

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.

Benjamin Cox
WebClient also allows POST, with UploadString, UploadData and UploadFile
Thomas Levesque
+4  A: 

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

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.
feroze
A: 

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.

synergetic
A: 

You can't control the timeout for WebClient, which I need to do right now. Grr...

Joe Rattz