为什么 HttpRequest.HttpMethod 是字符串而不是 Enum？
在 HttpRequest.HttpMethod 的参考在.NET Framework 中，请求类型是用System.String 类型声明的。
在 RFC 2616 中声明了所有 HTTP 请求方法（例如 POST、GET、PUT、DELETE ...）。
HttpWebRequest 和 中也有类似的行为.NET 的 >WebRequest 类。
Java 在 HttpURLConnection#setRequestMethod(String) 方法。
为什么这些语言设计者不考虑为这些 HTTP 方法实现枚举？
你有主意吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
RFC 2616 链接的第一句（已添加重点）：
也就是说，HTTP中的方法可以是任何东西。有一些“众所周知的”或常见的方法，其语义很好理解（好吧，应该很好理解 - 我仍然遇到对 GET/POST 不清楚的人）。
但任何应用程序都可以实现其他方法。希望客户端和服务器应用程序能够很好地理解这些其他方法的语义。
由于这些原因，枚举是不合适的，因为总是可能存在不适合该枚举的“其他”值。
更多来自 RFC 2616 的引用：
，以及
The first sentences of your RFC 2616 link (emphasis added):
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:
and,
该规范明确允许使用更多方法，因此无法枚举所有方法的集合。
The spec explicitly allows for more methods to be used, and so the set of all methods cannot be enumerated.
如果 HTTP 带有新方法，那么 java 和 C# 需要更新它们的枚举。他们什么时候更新？他们会发布补丁吗？或者会在下一个版本更新？因此，定义一个他们无法控制的值的枚举并不是一个明智的决定。
if HTTP Comes with a new method, then java and C# needs to update their enum. When will they update it? Will they release a patch? or will be updated in next version? So defining a enum on values which they dont control is not a wise decision.
正如 Damien 提到的，RFC2616 仅定义了通用方法。 HTTP 与 XML 一样，是一种可以扩展以支持其他格式的协议。
例如，假设我想实现一个名为“Encrypt”的特殊方法。如果 HTTP 库是枚举，它将失败并可能引发异常。当然，客户端必须了解这种特殊的请求类型，这就是为什么大多数扩展都是通过标头而不是命令来完成的。
HTTP 是一个可扩展的协议，但很少有人真正扩展它。
考虑这个简单的例子：
由于“方法”只是文本，并且用户可以在其中放置任何内容，那么 HTTP 处理程序必须能够处理它，对吗？
编辑：
事实证明，HTML 4 规范只允许 GET 和 POST 为有效值，但 HTTP 超出了这一范围。
As Damien mentions, RFC2616 only defines the common methods. HTTP, like XML, is a protocol that can be extended to support other formats.
For instance, suppose I wanted to implement a special method called "Encrypt". If the HTTP library were enums, it would fail and likely throw an exception. Of course the client would have to know about this special request type, which is why most extensions are done via headers rather than commands.
HTTP is an extensible protocol, but few people actually do extend it.
Consider this simple example:
Since "method" is just text, and the user could put anything there, then the HTTP handler has to be able to handle it, correct?
EDIT:
As it turns out, the HTML 4 specification only allows for GET and POST to be valid values, but HTTP goes beyond that.