WebClient vs. HttpWebRequest / HttpWebResponse

132

Parece-me que a maior parte do que pode ser realizado HttpWebRequest/Responsetambém pode ser realizada com a WebClientclasse. Eu li em algum lugar que WebClienté um invólucro de alto nível WebRequest/Response.
Até agora, não vejo nada que possa ser realizado com o HttpWebRequest/Responseque não possa ser realizado WebClientnem onde o HttpWebRequest / Response fornecerá um controle mais "refinado".

Quando devo usar o WebClient e quando HttpWebRequest/Response? (Obviamente, HttpWebRequest/Responsesão específicos de HTTP.)

Se o HttpWebRequest/Responsenível é inferior WebClient, o que posso realizar com o HttpWebRequest/Responseque não posso realizar WebClient?

.net  httpwebrequest  webclient  httpwebresponse 
— Dan
fonte

Respostas:

87

O uso HttpWebRequestfornece mais controle sobre a solicitação. Você pode definir cookies, cabeçalhos, protocolo, etc ... Na resposta, você também pode recuperar os cookies e cabeçalhos

— Thomas Levesque
fonte
14
Thomas, ainda não está convencido ... O WebClient possui uma propriedade Headers, é possível recuperar o cookie assim: String cookie = webClient.ResponseHeaders (“Set-Cookie”) e defina-o: webClient.Headers.Add ("Cookie", " CommunityServer-UserCookie… ");
— 7119 Dan
14
Usando HttpWebRequest, você pode definir um tempo limite. No WebClient, isso é impossível.
— ripper234
14
@ ripper234, na verdade, é possível: você só tem que herdar WebClient e substituir GetWebRequest para personalizar a HttpWebRequest
— Thomas Levesque
15
@ThomasLevesque se você está herdando webclient e substituindo o webrequest, parece inútil usar o webclient ...
— Hagai L
5
@HagaiL, eu discordo ... Você não tem que criar toda a pedido manualmente, você pode usar base.GetWebRequestpara criá-lo e em seguida, personalizar apenas o que você quer
— Thomas Levesque
54

HttpWebRequest expõe muito mais coisas que permitem controle de protocolo refinado, por exemplo: se você deseja usar o Keep-Alive, que conjunto de conexões usar, se é necessário armazenar em buffer gravações ou não, etc.

WebClientnão expõe tudo isso (embora você possa subclassificar WebCliente obter acesso ao objeto Request subjacente).

WebClienté útil para as situações em que você só quer fazer uma operação (por exemplo: POST / GET / upload Form) e não pode ser incomodado para criar e gerenciar o HttpWebRequest, RequestStream, HttpWebResponse, e fluxo de resposta.

— feroz
fonte
13
Além disso, há mais uma coisa que eu esqueci de mencionar. WebClient é um objeto Component, enquanto HttpWebRequest não é. O que isso significa? Bem, se você estiver usando o VisualStudio para criar um aplicativo GUI, poderá arrastar / soltar o componente WebClient no seu formulário e usá-lo para emitir solicitações para servidores HTTP / FTP etc.
— Feroze
14

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

Em vez disso, no Silverlight, você desejará usar o WebClient ou o HttpWebRequest. Qual é a diferença? Aqui está a versão do timheuer. O WebClient é uma implementação mais simples que realiza solicitações GET com muita facilidade e obtém um fluxo de resposta. O HttpWebRequest é ótimo para quando você precisa de um controle um pouco mais granular sobre a solicitação, precisa enviar cabeçalhos ou outras personalizações.

— Benjamin Cox
fonte
7
WebClient também permite POST, com UploadString, UploadData e UploadFile
— Thomas Levesque
@ThomasLevesque Existe uma versão mais recente das aulas hoje? Vejo que esta discussão é um pouco, hmm ... envelhecidos ...
— Konrad Viltersten
@KonradViltersten, acho que não houve muitas mudanças na classe WebClient. Para novos aplicativos, sugiro que você use o HttpClient, que também é muito fácil de usar e muito mais flexível.
— Thomas Levesque
1
@ThomasLevesque Certo, era nisso que eu estava pensando. Lembrei-me de http como a diferença no nome da classe e fui enganado pelo Http ... parte. Agora estou de volta ao caminho certo. Obrigado!
— Konrad Viltersten
12

A classe WebClient é executada no encadeamento da interface do usuário, portanto, a interface do usuário não responde enquanto os dados estão sendo baixados da Internet. Por outro lado, a classe HttpWebRequest não bloqueia o thread da interface do usuário e seu aplicativo é responsivo. Portanto, em aplicativos em que uma grande quantidade de dados deve ser baixada da Internet ou se a fonte dos dados é lenta para acessar, você deve usar a classe HttpWebRequest; em todos os outros casos, você deve usar a classe WebClient.

— Baaziz
fonte
1
O oposto é verdadeiro no WP7. Marechais HttpWebRequest de volta ao thread da interface do usuário no Mango, causando-me um fim de tristeza no momento. Grrr
— Cameron MacFarland
6
O WebClient também suporta métodos assíncronos.
— CyberMonk
6

Outra desvantagem de WebClient é que ignora o HTTP ContentType's charsetvalor quando você usá-lo para obter o texto de resposta. Você precisa definir explicitamente a codificação por meio da Encodingpropriedade

— Sam
fonte
Este é um bom ponto; e não é apenas uma questão de definir a Encoding- você não pode saber a codificação até depois da solicitação, portanto, a API do WebClient torna muito improvável que você possa baixar corretamente uma string em uma codificação desconhecida.
— Eamon Nerbonne
5

O "HtttpWebRequest" está obsoleto no .NET 4.5. Agora, essa classe é apenas interna.

— Julio Spader
fonte
2
De fato. Use em WebRequestvez disso.
— Silkfire #
2
A classe não é obsoleta, os construtores são. E a turma não é interna, ainda é pública.
— user247702
2

Um exemplo: publicar dados e recuperar dados processados ​​em um ciclo de solicitação / resposta parece impossível com o WebClient, mas você pode fazer isso com HtttpWebRequest.

— sinérgico
fonte
2
Basta usar WebClient.UploadString ou WebClient.UploadData para executar um POST e recuperar uma sequência de caracteres de resposta ou matriz de bytes.
— 11133 samjudson
2
Para esclarecer, o valor de retorno do UploadString é uma string e o valor de retorno do método UploadData é uma matriz de bytes.
— Norman H
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.