C# HttpWebRequest 与 WebRequest
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/896253/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
C# HttpWebRequest vs WebRequest
提问by Unknown
I saw this piece of code:
我看到了这段代码：
var request = (HttpWebRequest) WebRequest.Create("http://www.google.com");
Why do you need to cast (HttpWebRequest)? Why not just use HttpWebRequest.Create? And why does HttpWebRequest.Createmake a WebRequest, not a HttpWebRequest?
为什么需要投射(HttpWebRequest)？为什么不直接使用HttpWebRequest.Create？为什么HttpWebRequest.Createmake a WebRequest，而不是 a HttpWebRequest？
采纳答案by David Wengier
The Createmethod is static, and exists only on WebRequest. Calling it as HttpWebRequest.Createmight look different, but its actually compiled down to calling WebRequest.Create. It only appears to be on HttpWebRequestbecause of inheritance.
该Create方法是静态的，仅存在于 上WebRequest。调用它HttpWebRequest.Create可能看起来不同，但它实际上编译为调用WebRequest.Create. 它似乎只是HttpWebRequest因为继承。
The Createmethod internally, uses the factory pattern to do the actual creation of objects, based on the Uriyou pass in to it. You could actually get back other objects, like a FtpWebRequestor FileWebRequest, depending on the Uri.
该Create方法在内部使用工厂模式根据Uri您传递给它的内容来实际创建对象。您实际上可以取回其他对象，例如 aFtpWebRequest或FileWebRequest，具体取决于Uri.
回答by Orhan Cinar
WebRequestis an abstract class, which has a factory method Createthat, depending on the URL passed in, creates an instance of a concrete subclass. Whether you need or want
HttpWebRequest httpreq = (HttpWebRequest)WebRequest.Create(strUrl);instead of
WebRequest req = WebRequest.Create(strUrl);depends on your needs, and on what kind of URLs you pass in.
WebRequest是一个抽象类，它有一个工厂方法Create，根据传入的 URL，创建一个具体子类的实例。您是否需要或想要
HttpWebRequest httpreq = (HttpWebRequest)WebRequest.Create(strUrl);而不是
WebRequest req = WebRequest.Create(strUrl);取决于您的需求，以及您传入的 URL 类型。
If you only pass in HTTP: URL's, then the former code allows you to access the properties and methods the subclass HttpWebRequestimplements in addition to those defined on the base class WebRequest. But if you passed in a FTP: URL then the attempt to cast to HttpWebRequestwould fail.
如果您只传入 HTTP: URL's，那么前面的代码允许您访问子类HttpWebRequest实现的属性和方法，以及在基类上定义的属性和方法WebRequest。但是，如果您传入 FTP: URL，则尝试强制转换为HttpWebRequest将失败。
The latter is generic and won't fail on any of the types of supported URL's but of course without casting to any subclass you can only access the properties and methods the base class defines.
后者是通用的，不会在任何受支持的 URL 类型上失败，但当然，如果不强制转换为任何子类，您只能访问基类定义的属性和方法。
-- via Martin Honnen
——通过马丁·霍南
回答by Kevin
The cast is only necessary when you need access to members unique to HttpWebRequest. The idea is that if the properties/methods supported on WebRequest are sufficient, then you can write an application that will work against many types of request/response protocols. In this case the URI could be something given by the user using any protocol supported by pluggable protocols. New protocols can even be supported without altering the original software.
仅当您需要访问 HttpWebRequest 独有的成员时才需要转换。这个想法是，如果 WebRequest 支持的属性/方法足够了，那么您可以编写一个应用程序，该应用程序将适用于多种类型的请求/响应协议。在这种情况下，URI 可以是用户使用可插入协议支持的任何协议给出的内容。甚至可以在不改变原始软件的情况下支持新协议。
If your application needs more control over features specific to a particular protocol then you can restrict requestUri to your supported scheme(s) and cast WebRequest to the appropriate protocol-specific subclass. This limits the protocols supported by your application, but enables you to tweak protocol-specific features.
如果您的应用程序需要更多地控制特定于特定协议的功能，那么您可以将 requestUri 限制为您支持的方案并将 WebRequest 转换为适当的特定于协议的子类。这限制了您的应用程序支持的协议，但使您能够调整特定于协议的功能。
