WebClient vs. HttpWebRequest/HttpWebResponse

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?

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

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.

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.

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.

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.

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

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

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.