#swift #foundation
#java #.net #язык-дизайн
Вопрос:
В ссылке HttpRequest.HttpMethod на .NET Framework тип запроса объявляется с System.String помощью type .
В RFC 2616 объявлены все методы HTTP-запроса (например, POST, GET, PUT, DELETE …).
Аналогичное поведение наблюдается HttpWebRequest и WebRequest в классах .NET.
Java имеет аналогичный подход к HttpURLConnection#setRequestMethod(String) методу.
Почему разработчики этих языков не рассматривают возможность реализации enum для этих методов HTTP?
У вас есть идея?
Ответ №1:
Первые предложения вашей ссылки на RFC 2616 (курсив добавлен):
Набор общих методов для HTTP / 1.1 определен ниже. Хотя этот набор можно расширить…
То есть метод в HTTP может быть любым. Существуют «хорошо известные» или распространенные методы, семантика которых хорошо понятна (ну, хорошо, должна быть хорошо понята — я все еще сталкиваюсь с людьми, неясными в GET / POST).
Но любое приложение может реализовать другие методы. Надеюсь, семантика этих других методов будет хорошо понятна между клиентскими и серверными приложениями.
По этим причинам перечисление было бы неуместным, поскольку всегда могут быть «другие» значения, которые не вписываются в это перечисление.
Больше цитат из RFC 2616:
Практические информационные системы требуют большей функциональности, чем простой поиск, включая поиск, обновление интерфейса и аннотацию. HTTP допускает открытый набор методов и заголовков, которые указывают цель запроса
и,
Маркер метода указывает метод, который должен быть выполнен на ресурсе, идентифицированном с помощью запроса-URI. Этот метод чувствителен к регистру символов.
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
Комментарии:
1. я согласен, но когда вы смотрите на перечисление System.Web.Mvc.HttpVerbs, я немного теряюсь. Хорошо это или плохо? Кроме того, я думаю, что поместить это перечисление в пространство имен System.Web.Mvc — неправильное решение, несмотря ни на что.
2. @liuhongbo — Каждое место, которое я вижу, которое используется в другом месте
Mvcпространства имен, похоже, поддерживает две перегрузки — одна принимает значение из этого перечисления, другая принимает строку (или массив строк). Это другой способ делать что-то, но, похоже, им все еще нужно было обеспечить выпускной клапан, когда метод не входит в обычно используемый набор.3. В качестве примера для этого ответа PATCH отсутствует в списке метода HttpMethod
Ответ №2:
Спецификация явно допускает использование большего количества методов, и поэтому набор всех методов не может быть перечислен.
Ответ №3:
если HTTP поставляется с новым методом, то java и C # должны обновить свое перечисление. Когда они обновят его? Выпустят ли они патч? или будет обновлен в следующей версии? Таким образом, определение перечисления значений, которые они не контролируют, не является мудрым решением.
Комментарии:
1. Каким образом? Я не сравниваю HTTP и перечисления. Это как бананы и старшеклассники. Ваш ответ не является пояснительным.
2. и чтобы расширить ответ, методы могут быть расширены, так кто же будет поддерживать эту библиотеку enum???
3. тем не менее, я ничего не понимаю из ваших комментариев по этому поводу.
4. если HTTP поставляется с новым методом, то java и C # должны обновить свои enum . Когда они его обновят? Выпустят ли они патч? или будет обновлен в следующей версии? Поэтому определение enum для значений, которые они не контролируют, не является мудрым решением…
Ответ №4:
Как упоминает Дэмиен, RFC2616 определяет только общие методы. HTTP, как и XML, является протоколом, который может быть расширен для поддержки других форматов.
Например, предположим, что я хотел реализовать специальный метод под названием «Encrypt». Если бы HTTP-библиотека была enums, она завершилась бы с ошибкой и, вероятно, выдала бы исключение. Конечно, клиент должен знать об этом специальном типе запроса, поэтому большинство расширений выполняются с помощью заголовков, а не команд.
HTTP — это расширяемый протокол, но мало кто на самом деле расширяет его.
Рассмотрим этот простой пример:
<form method="Foo" action="http://someurl"></form>
Поскольку «метод» — это просто текст, и пользователь может поместить туда что угодно, тогда обработчик HTTP должен быть в состоянии обработать это, правильно?
Редактировать:
Как оказалось, спецификация HTML 4 допускает только допустимые значения GET и POST, но HTTP выходит за рамки этого.