Почему в формах HTML нет методов PUT и DELETE?

265

HTML4 / XHTML1 допускает только GET и POST в формах, теперь кажется, что HTML5 сделает то же самое. Есть предложение добавить эти два, но оно, похоже, не набирает обороты. По каким техническим или политическим причинам не было включено PUT и DELETE в черновик спецификации HTML5?

FilipK
источник
7
HTML является языком разметки, HTTP является протоколом
трещотка урод
51
@ rachet freak: я знаю об этом. Тем не менее, я спрашиваю конкретно о HTML, так как он определяет только GET и POST как разрешенные <form>методы.
FilipK
Типичным сценарием является форма с табличными данными, в которой пользователю нужно ставить больше строк или нет, так как «больше строк» ​​является решением пользователя. Использование Javascript + POST является искусственным, возможно, HTML6 покажет альтернативную функцию FORM для выполнения такого рода операций.
Питер Краусс
Я ответил на этот вопрос, когда кто-то спросил его о переполнении стека, и почувствовал, что мой вклад может кое-что добавить к превосходным ответам, приведенным выше, для тех, кто читает это далеко внизу страницы: o) Почему браузеры не поддерживают запросы PUT и DELETE и когда они будут?
Николас Шенкс
4
это все еще в силе? w3.org/TR/form-http-extensions/#http-delete-form
Джефф

Ответы:

348

Это увлекательный вопрос. Все остальные ответы здесь носят умозрительный характер, а в некоторых случаях совершенно неверны. Вместо того, чтобы писать свое мнение здесь, я действительно провел некоторое исследование и нашел оригинальные источники, которые обсуждают, почему удаление и вставка не являются частью стандарта формы HTML5.

Как оказалось, эти методы были включены в несколько ранних черновиков HTML5 (!), Но позже были удалены в последующих черновиках . Mozilla также реализовала это в бета-версии Firefox .

Что послужило основанием для удаления этих методов из проекта? W3C обсуждал эту тему в сообщении об ошибке 10671 . Майк Амундсен высказался в пользу этой поддержки:

Выполнение PUT и DELETE для изменения ресурсов на исходном сервере является простым для современных веб-браузеров, использующих объект XmlHttpRequest. Для незашифрованных браузерных взаимодействий это не так просто. [...]

Этот шаблон требуется так часто, что несколько часто используемых веб-фреймворков / библиотек создают «встроенный» обходной путь. [...]

Другие соображения:

  • Использование POST в качестве туннеля вместо использования PUT / DELETE может привести к несоответствию кэширования (например, ответы POST кэшируются , ответы PUT - нет (6), ответы DELETE - нет (7))
  • Использование неидемпотентного метода (POST) для выполнения идемпотентной операции (PUT / DELETE) усложняет восстановление из-за сбоев сети (например, «Безопасно ли повторять это действие?»).
  • [...]

Стоит прочитать весь его пост.

Том Уордроп также делает интересное замечание:

HTML неразрывно связан с HTTP. HTML - это человеческий интерфейс HTTP. Поэтому автоматически возникает вопрос, почему HTML не поддерживает все соответствующие методы в спецификации HTTP. Почему машины могут ПОСТАВЛЯТЬ и УДАЛЯТЬ ресурсы, а люди - нет? [...]

Противоречиво, что хотя HTML идет на все, чтобы обеспечить семантическую разметку, на сегодняшний день он не предпринимал таких усилий для обеспечения семантических HTTP-запросов.

Иан Хиксон в конце концов исправил ошибку « Не исправлю» со следующим объяснением:

PUT как метод формы не имеет смысла, вы не хотите помещать полезную нагрузку формы. DELETE имеет смысл только в том случае, если нет полезной нагрузки, поэтому он не имеет особого смысла и с формами.

Однако это еще не конец истории! Проблема была закрыта в трекере ошибок W3C и перешла в трекер проблем рабочей группы HTML:

https://www.w3.org/html/wg/tracker/issues/195

На данный момент кажется, что главная причина, по которой эти методы не поддерживаются, заключается в том, что никто не нашел время для того, чтобы написать для него исчерпывающую спецификацию.

Марк Э. Хаас
источник
70
+1 за то, что он приложил усилия для исследования и выкопал несколько внешних ссылок, чтобы правильно ответить на вопрос.
6
@shivakumar Я думаю, что вы действительно спрашиваете, зачем беспокоиться о HTML, когда JavaScript уже может сделать эту работу? Это справедливый вопрос. Я полагаю, что вопрос ОП исходит скорее из любопытства, чем из практичности. HTML и HTTP являются двумя стандартами, созданными друг для друга, и, тем не менее, HTML, похоже, не знает о некоторых основных свойствах HTTP. "Почему?" это естественный вопрос, чтобы задать.
Марк Э. Хаас
23
Конечно, вы должны включить полезную нагрузку для PUT, а для DELETE это возможно? Кроме того, если «не имеет большого смысла с формами», то почему люди спрашивают об этом и почему так много, если в программное обеспечение он встроил обходные пути. Странно, как один человек может просто решить, что нужно или хочет остальному миру ...
Джонатан.
4
@mehaase Кроме того, возможно, это только я, но я думаю, что списки рассылки являются гораздо лучшим местом для обсуждения, чем для общей поддержки предложения. Я не склонен создавать новый поток в списке рассылки public-html-comments, просто чтобы сказать: «Мне нравится это предложение; формы должны иметь возможность использовать другие методы HTTP». Как человек, выросший в современной сети, я хочу знать: «Где кнопка upvote?» ;-)
Ajedi32
6
@ Ajedi32 вот этот пост: lists.w3.org/Archives/Public/public-html/2015Feb/0000.html Я призываю всех, кому интересно, ответить на этот пост в списке рассылки public-html.
Марк Э. Хаас
12

GET и POST имеют четкое, нейтральное к содержанию обоснование. GET предназначен для получения содержимого URL-адреса таким образом, чтобы его можно было безопасно повторить и, возможно, кэшировать. POST - это что-то, что не безопасно повторять, спекулятивно выполнять или кэшировать.

Не было аналогичного обоснования для PUT или DELETE. Они оба полностью покрыты POST. Создание или уничтожение ресурса - это операции, которые небезопасно повторять, небезопасно выполнять спекулятивно и не должны кэшироваться. Для них не требуется никакой дополнительной специальной семантики.

Так что в принципе нет никакой пользы.

Дэвид Шварц
источник
22
Хотя POST охватывает PUT и DELETE, я все еще вижу преимущество использования отдельных методов. Все они описаны в спецификации HTTP, и их использование рекомендуется в REST.
FilipK
10
@ Дэвид: Это было бы особенность .
Донал Феллоуз
15
Смысл в том, что POST и DELETE имеют разные, почти противоположные значения. Вы утверждаете, что POST полностью покрывает DELETE, но POST не идемпотентен, а DELETE - это. Как вы это объясните? w3.org/Protocols/rfc2616/rfc2616-sec9.html
Марк Э.
14
Умная аналогия, но вы переопределяете, что означает «покрытие». В своем первоначальном ответе вы имеете в виду «охватывает», как и «поддерживает все те же варианты использования». Здесь вы переопределяете «покрытия», чтобы обозначить некие таксономические отношения. Давайте разберем язык: POST не поддерживает те же сценарии использования, что и DELETE из-за разницы в идемпотентности. GET не поддерживает те же сценарии использования, что и DELETE, из-за различной семантики. Поддержка DELETE увеличит функциональность пользовательского агента.
Марк Э. Хааз
13
Я не согласен с этим ответом. неPOST является идемпотентом, поэтому, когда вы нажимаете «назад» в своем браузере, он отображает некрасивую страницу, которая говорит, что форму необходимо отправить повторно. Однако , если бы он был PUT, он мог бы безопасно переслать PUTзапрос, чтобы отобразить любую страницу, которую вы должны получить. При условии, конечно, никто не испортит API, создав своего рода DELETE /resource/latest.
arg20
12

Эта проблема была поднята в 2010 году, поскольку ошибка 10671 предусматривает добавление поддержки PUT и DELETE в качестве методов формы .

У этой «особенности» было небольшое количество откатов и некоторая неуклюжесть, но в конечном итоге это обострилось из-за двух проблем в трекере ошибок рабочих групп:

Проблема ISSUE-196 привела к принятию консенсусом решения не вносить изменений в спецификацию, поскольку спецификация HTML в настоящее время не ограничивает обработку ответов на запросы POST. Я полагаю, что эта конкретная проблема возникла при попытке согласовать часто используемые шаблоны перенаправления POST и то, как серверы ReSTful часто предоставляют ответы 2xx с короткими сообщениями, а не с помощью чего-либо полезного для отображения в браузере.

Выпуск -195 был представлен на кафедре. Кэмерон Джонс выступил добровольно, написав предложение об изменении 18 января 2012 года, которое он представил, чтобы стать первым рабочим проектом 29 мая 2014 года. Проект будет проходить через процесс рекомендаций W3C .

Если повезет, это скоро станет рекомендацией W3C и будет реализовано поставщиками браузеров и станет большим шагом вперед в устранении блокировщиков для создания унифицированных, семантических и дружественных браузеру сервисов ReSTful. Я предполагаю, что это вызовет интересную эволюцию в шаблонах обслуживания. Джон Мур (Jon Moore) говорит о том, что API-интерфейсы Hypermedia заслуживают внимания, меня это заинтересовало, но они упали с первого же препятствия (вот этого).

Стюарт Уэйкфилд
источник
5

Насколько я понимаю, браузеры не знают, что делать после отправки PUT или DELETE. POST обычно перенаправляет на соответствующую страницу, но PUT и DELETE обычно этого не делают. Это делает их подходящими для вызова через ajax или нативную программу, но не из формы веб-браузера.

Я не могу сейчас это скрыть, но я помню, как читал один из списков рассылки html5, когда они обсуждали это.

maxpolun
источник
4
Есть ли причина, по которой PUT и DELETE не могут или не перенаправляют так же, как POST?
Райан Х
3
@maxpolun Это, вероятно, список рассылки, на который вы ссылаетесь: lists.w3.org/Archives/Public/public-html-wg-issue-tracking/…
jordanbtucker
2
@RyanH Там нет. Каждое приложение, с которым я столкнулся, отправляет запрос на удаление и отвечает перенаправлением на индекс.
Qwertie
5

история

Я думаю, что стоит упомянуть о первом появлении html-форм в RFC1866 (раздел 8.1) . Здесь атрибут метода определяется следующим образом:

METHOD
        selects a method of accessing the action URI. The set of
        applicable methods is a function of the scheme of the
        action URI of the form. See 8.2.2, "Query Forms:
        METHOD=GET" and 8.2.3, "Forms with Side-Effects:
        METHOD=POST".

Дальнейшие объяснения находятся в Разделе 8.2.2 - GET и Разделе 8.2.3 - POST

Имейте в виду, что HTML 2.0 (ноябрь 1995 г.) был указан до HTTP 1.0 (май 1996 г.). Таким образом, все использовали HTTP только с GET (с HTTP 0.9) или с расширением POST. Но только несколько веб-серверов поддерживают PUT и DELETE (как указано в Приложении HTTP 1.0 ).

мысли

Если вы думаете о том, как развитие семантической сети Бернерс-Ли могло развиваться, кажется очевидным, что она перешла от реальных проблем к общей концепции. Сначала он хотел поделиться документами. Поэтому ему нужна разметка. Затем он захотел запросить у баз данных контент, поэтому ему нужны были формы. Затем он хотел поместить новые данные в базу данных. Поэтому он использовал формы с GET и POST. После этого он, возможно, понял, что вы можете выполнять каждую операцию CRUD с данными удаленно, поэтому HTTP был расширен, но не HTML, потому что было слишком поздно (только несколько серверов поддерживали новые операции CRUD).

schmijos
источник
-2

Просто выбрасываю дикие предположения, но, возможно, потому, что HTTP не очень хорошо справляется с управлением доступом в лучшие времена, и последнее, что всем нужно, - это еще больше способов для вредоносных URL-адресов скомпрометировать плохо защищенный веб-сайт и / или приложение.

HTTP не очень хороший протокол для передачи файлов, кроме загрузки с сервера на клиент. Используйте FTP - или еще лучше, SFTP.

Shadur
источник
12
Безопасность не имеет к этому никакого отношения. Вы все еще можете делать запросы PUT / Delete через HTTP. curl --request PUT http://A.B.c/indexВопрос в том, почему вы можете получить доступ к этим командам через HTML.
Мартин Йорк,
5
-1 Дикие догадки вообще не помогают на ТАК.
Марк Э. Хааз
-4

Get и post - это форматы передачи данных запроса.

Я полагаю, что вы спрашиваете о том, чтобы сделать отправку формы в RESTFUL сервис. Но не имеет смысла изменять стандарт http-запроса, чтобы сделать предположения целью http-запроса. Информация о цели, которую заполняет запрос, лучше всего обрабатывается в полях ввода.

Наличие адреса, get и post позволяет серверу правильно интерпретировать запрос и его входные значения. Оттуда входные значения позволяют вам делать открытые запросы к серверу и делать все, что вы хотите. Например, у вас может быть поле со значениями «положить» и «удалить»

Джо
источник
5
-1 «Получить и отправить - это форматы передачи данных запроса.» Нет, это методы HTTP, а не «форматы».
Марк Э. Хаас