C # HttpWebRequest frente a WebRequest


112

Vi este fragmento de código:

var request = (HttpWebRequest) WebRequest.Create("http://www.google.com");

¿Por qué necesitas lanzar (HttpWebRequest)? ¿Por qué no usar HttpWebRequest.Create? ¿Y por qué hace HttpWebRequest.Createa WebRequest, no a HttpWebRequest?


relacionado con la publicación: stackoverflow.com/q/8209781/274502
cregox

Respuestas:


134

El Createmétodo es estático y solo existe en WebRequest. Llamarlo como HttpWebRequest.Createpuede parecer diferente, pero en realidad está compilado para llamar WebRequest.Create. Solo parece estar encendido HttpWebRequestdebido a la herencia.

El Createmétodo utiliza internamente el patrón de fábrica para realizar la creación real de objetos, en función de lo que Urile pasa. De hecho, podría recuperar otros objetos, como un FtpWebRequesto FileWebRequest, según el Uri.


3
Esto es correcto. Hubiera sido bueno si hubiera una manera de obtener una HttpWebRequest de HttpWebRequest.Create o algo como HttpWebRequest.CreateHttp sin conversión. El primero sería algo así como una nueva creación estática pública de HttpWebRequest (cadena de URL). De cualquier manera, si la URL no era HTTP (s), debería arrojar alguna InvalidArgumentException.
Matthew Flaschen

4
Una muy buena explicación de una decisión de diseño muy extraña (¿me atrevo a decir mal?) Por parte de los creadores de .NET.
IJ Kennedy

2
@IJKennedy Estoy completamente de acuerdo, una decisión de diseño muy extraña, ilógica y poco práctica.
Aidiakapi

8
HttpWebRequest.CreateHttp existe y crea una instancia de HttpWebRequest.
Peter Meinl

4
@Bobson WebRequest.CreateHttpestá en 4.5
Mark

31

WebRequestes una clase abstracta, que tiene un método de fábrica Createque, dependiendo de la URL pasada, crea una instancia de una subclase concreta. Si lo necesita o desea en HttpWebRequest httpreq = (HttpWebRequest)WebRequest.Create(strUrl);lugar de WebRequest req = WebRequest.Create(strUrl);depende de sus necesidades y del tipo de URL que ingrese.

Si solo pasa HTTP: URL, entonces el código anterior le permite acceder a las propiedades y métodos que HttpWebRequestimplementa la subclase además de los definidos en la clase base WebRequest. Pero si pasa en un FTP: URL, el intento de transmisión HttpWebRequestfallará.

Este último es genérico y no fallará en ninguno de los tipos de URL compatibles, pero, por supuesto, sin conversión a ninguna subclase, solo puede acceder a las propiedades y métodos que define la clase base.

- a través de Martin Honnen


12

El elenco solo es necesario cuando necesita acceso a miembros exclusivos de HttpWebRequest. La idea es que si las propiedades / métodos admitidos en WebRequest son suficientes, entonces puede escribir una aplicación que funcione con muchos tipos de protocolos de solicitud / respuesta. En este caso, el URI podría ser algo proporcionado por el usuario utilizando cualquier protocolo compatible con protocolos conectables. Incluso se pueden admitir nuevos protocolos sin alterar el software original.

Si su aplicación necesita más control sobre las características específicas de un protocolo en particular, puede restringir requestUri a sus esquemas admitidos y enviar WebRequest a la subclase específica del protocolo correspondiente. Esto limita los protocolos admitidos por su aplicación, pero le permite modificar funciones específicas del protocolo.

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.