In the Reference of HttpRequest.HttpMethod
of .NET Framework, request type is declared with System.String
type.
In RFC 2616 all HTTP request methods are declared (e.g. POST, GET, PUT, DELETE...).
There's also similar behavior in HttpWebRequest
and WebRequest
classes of .NET.
Java has the similar approach on HttpURLConnection#setRequestMethod(String)
method.
Why do these language designers do not consider implementing an enum for those HTTP methods?
Do you have an idea?
The first sentences of your RFC 2616 link (emphasis added):
The set of common methods for HTTP/1.1 is defined below. Although this set can be expanded...
That is to say, the method in HTTP may be anything. There are "well known" or common methods, the semantics of which are well understood (well, okay, should be well understood - I still encounter people unclear on GET/POST).
But any application may implement other methods. Hopefully, the semantics of those other methods will be well understood between client and server applications.
For these reasons, an enum would be inappropriate, since there can always be "other" values that wouldn't fit in that enum.
More quotes from the RFC 2616:
Practical information systems require more functionality than simple retrieval, including search, front-end update, and annotation. HTTP allows an open-ended set of methods and headers that indicate the purpose of a request
and,
The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case-sensitive.
Method = "OPTIONS" ; Section 9.2 | "GET" ; Section 9.3 | "HEAD" ; Section 9.4 | "POST" ; Section 9.5 | "PUT" ; Section 9.6 | "DELETE" ; Section 9.7 | "TRACE" ; Section 9.8 | "CONNECT" ; Section 9.9 | extension-method extension-method = token
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With