WebClient vs. HttpWebRequest / HttpWebResponse

132

Me parece que la mayor parte de lo que se puede lograr HttpWebRequest/Responsetambién se puede lograr con la WebClientclase. Leí en alguna parte que WebClientes un contenedor de alto nivel para WebRequest/Response.
Hasta ahora, no puedo ver nada que se pueda lograr con HttpWebRequest/Responseeso que no se puede lograr WebClient, ni donde HttpWebRequest / Response le dará más control "de grano fino".

¿Cuándo debo usar WebClient y cuándo HttpWebRequest/Response? (Obviamente, HttpWebRequest/Responseson específicos de HTTP).

Si HttpWebRequest/Responseson de nivel inferior WebClient, ¿qué puedo lograr con lo HttpWebRequest/Responseque no puedo lograr WebClient?

.net  httpwebrequest  webclient  httpwebresponse 
— Dan
fuente

Respuestas:

87

El uso HttpWebRequestle da más control sobre la solicitud. Puede configurar cookies, encabezados, protocolos, etc. En la respuesta, también puede recuperar las cookies y los encabezados.

— Thomas Levesque
fuente
14
Thomas, aún no está convencido ... WebClient tiene una propiedad Headers, puede recuperar la cookie de esta manera: String cookie = webClient.ResponseHeaders ("Set-Cookie") y configurarlo: webClient.Headers.Add ("Cookie", " CommunityServer-UserCookie ... ");
— Dan, el
14
Usando HttpWebRequest puede definir un tiempo de espera. En WebClient, eso es imposible.
— ripper234
14
@ ripper234, en realidad es posible: solo tiene que heredar WebClient y anular GetWebRequest para personalizar HttpWebRequest
— Thomas Levesque
15
@ThomasLevesque si estás heredando el cliente web y anulando la búsqueda de la web, parece inútil usar el cliente web ...
— Hagai L
55
@HagaiL, no estoy de acuerdo ... No tiene que crear toda la solicitud manualmente, puede usarla base.GetWebRequestpara crearla y luego personalizar exactamente lo que desea
— Thomas Levesque
54

HttpWebRequest expone muchas más cosas que le permiten un control de protocolo de grano fino, por ejemplo: si desea usar Keep-Alive, qué grupo de conexiones usar, si almacenar o no las escrituras en el búfer, etc.

WebClientno expone todos esos (aunque puede subclasificar WebClienty acceder geta al objeto Request subyacente).

WebClientes útil para aquellas situaciones en las que simplemente quiere hacer una operación (por ejemplo: de POST / GET / formulario de carga) y no puede ser molestado en crear y gestionar la HttpWebRequest, RequestStream, HttpWebResponse, y la secuencia de respuesta.

— congelar
fuente
13
Además, hay una cosa más que olvidé mencionar. WebClient es un objeto Componente, mientras que HttpWebRequest no lo es. Qué significa eso? Bueno, si está utilizando VisualStudio para crear una aplicación GUI, puede arrastrar / soltar el componente WebClient en su formulario y usarlo para emitir solicitudes a servidores HTTP / FTP, etc.
— congelado
14

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

En cambio, en Silverlight querrás usar WebClient o HttpWebRequest. ¿Cual es la diferencia? Aquí está la versión de Timheuer. WebClient es una implementación más simple que realiza solicitudes GET con mucha facilidad y obtiene un flujo de respuesta. HttpWebRequest es ideal para cuando necesita un control un poco más granular sobre la solicitud, necesita enviar encabezados u otras personalizaciones.

— Benjamin Cox
fuente
77
Cliente Web también permite POST, con UploadString, UploadData y UploadFile
— Thomas Levesque
@ThomasLevesque ¿Hay una versión más nueva de las clases hoy? Veo que esta discusión es un poco, hmm ... envejecida ...
— Konrad Viltersten
@KonradViltersten, no creo que haya habido muchos cambios en la clase WebClient. Para las nuevas aplicaciones, le sugiero que use HttpClient, que también es muy fácil de usar y mucho más flexible.
— Thomas Levesque
1
@ThomasLevesque Correcto, en eso estaba pensando. Recordé http como la diferencia en el nombre de la clase y me engañé por Http ... parte. Ahora estoy de vuelta en el camino correcto. ¡Gracias!
— Konrad Viltersten
12

La clase WebClient se ejecuta en el hilo de la interfaz de usuario, por lo que la interfaz de usuario no responde mientras se descargan datos de Internet. Por otro lado, la clase HttpWebRequest no bloquea el hilo de la interfaz de usuario y su aplicación responde. Por lo tanto, en aplicaciones donde se va a descargar una gran cantidad de datos de Internet o si el origen de los datos es de acceso lento, debe usar la clase HttpWebRequest; en todos los demás casos, debe usar la clase WebClient.

— Baaziz
fuente
1
Lo contrario es cierto en WP7. HttpWebRequest solicita a los mariscales que vuelvan al hilo de la interfaz de usuario en Mango, lo que me causa un sinfín de dolor en este momento. Grrr
— Cameron MacFarland
66
WebClient también admite métodos asincrónicos.
— CyberMonk
6

Otra desventaja de WebClientes que ignora el HTTP ContentType's charsetvalor cuando lo utiliza para obtener el texto de respuesta. Debe establecer explícitamente la codificación a través de la Encodingpropiedad.

— Sam
fuente
Este es un buen punto; y no es solo una cuestión de configurar Encoding: no puede conocer la codificación hasta después de la solicitud, por lo que la API de WebClient hace que sea muy poco probable que pueda descargar correctamente una cadena en una codificación desconocida.
— Eamon Nerbonne
5

El "HtttpWebRequest" está obsoleto en .NET 4.5. Ahora, esta clase es solo interna.

— Julio Spader
fuente
2
En efecto. Usar en su WebRequestlugar.
— silkfire
2
La clase no es obsoleta, los constructores sí. Y la clase no es interna, sigue siendo pública.
— user247702
2

Un ejemplo: publicar datos y recuperar datos procesados ​​en un ciclo de solicitud / respuesta parece imposible con WebClient, pero puede hacerlo con HtttpWebRequest.

— sinergético
fuente
2
Simplemente use WebClient.UploadString o WebClient.UploadData para realizar una POST y recuperar una cadena de respuesta o una matriz de bytes.
— samjudson
2
Para aclarar, el valor de retorno de UploadString es una cadena y el valor de retorno del método UploadData es una matriz de bytes.
— Norman H
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.