C # HttpWebRequest frente a WebRequest

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?

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.

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

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.