114

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.Create make a WebRequest, not a HttpWebRequest?

Eonasdan
  • 7,287
  • 8
  • 52
  • 79
Unknown
  • 44,664
  • 26
  • 136
  • 177

3 Answers3

135

The Create method is static, and exists only on WebRequest. Calling it as HttpWebRequest.Create might look different, but its actually compiled down to calling WebRequest.Create. It only appears to be on HttpWebRequest because of inheritance.

The Create method internally, uses the factory pattern to do the actual creation of objects, based on the Uri you pass in to it. You could actually get back other objects, like a FtpWebRequest or FileWebRequest, depending on the Uri.

David Wengier
  • 9,875
  • 5
  • 37
  • 43
  • 3
    This is right. It would have been nice if there was a way to get a HttpWebRequest from either HttpWebRequest.Create or something like HttpWebRequest.CreateHttp without casting. The first would be something like public new static HttpWebRequest Create(string url). Either way, if the url wasn't HTTP(s), it should just throw some InvalidArgumentException. – Matthew Flaschen May 22 '09 at 06:06
  • 4
    A very nice explanation of a very strange design decision (dare I say wrong?) by the .NET creators. – I. J. Kennedy Oct 29 '10 at 16:28
  • 2
    @I.J.Kennedy I completely agree, a very strange, illogical, and unpractical design decision. – Aidiakapi Sep 08 '11 at 11:53
  • 8
    HttpWebRequest.CreateHttp does exist and does create a HttpWebRequest instance. – Peter Meinl May 07 '12 at 16:55
  • This didn't answer it to me, at all (though, after I did understand the difference, this makes all sense). [Researching more and more, did](http://stackoverflow.com/a/17026797/274502). To me, seems like the difference is actually **just a *code design* choice**. – cregox Jun 10 '13 at 14:57
  • @PeterMeinl - As far as I can tell, that only exists in the PCL version. – Bobson Jan 15 '14 at 22:28
  • 4
    @Bobson `WebRequest.CreateHttp` is [in 4.5](https://msdn.microsoft.com/en-us/library/ff382776(v=vs.110).aspx) – Mark Jun 09 '15 at 05:29
33

WebRequest is an abstract class, which has a factory method Create that, 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.

If you only pass in HTTP: URL's, then the former code allows you to access the properties and methods the subclass HttpWebRequest implements in addition to those defined on the base class WebRequest. But if you passed in a FTP: URL then the attempt to cast to HttpWebRequest would fail.

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.

-- via Martin Honnen

SteveC
  • 14,716
  • 23
  • 93
  • 165
Orhan Cinar
  • 8,325
  • 2
  • 34
  • 48
12

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.

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.

Kevin
  • 7,734
  • 4
  • 26
  • 31