HTML4 / XHTML1 допускает только GET и POST в формах, теперь кажется, что HTML5 сделает то же самое. Есть предложение добавить эти два, но оно, похоже, не набирает обороты. По каким техническим или политическим причинам не было включено PUT и DELETE в черновик спецификации HTML5?
265
<form>
методы.Ответы:
Это увлекательный вопрос. Все остальные ответы здесь носят умозрительный характер, а в некоторых случаях совершенно неверны. Вместо того, чтобы писать свое мнение здесь, я действительно провел некоторое исследование и нашел оригинальные источники, которые обсуждают, почему удаление и вставка не являются частью стандарта формы HTML5.
Как оказалось, эти методы были включены в несколько ранних черновиков HTML5 (!), Но позже были удалены в последующих черновиках . Mozilla также реализовала это в бета-версии Firefox .
Что послужило основанием для удаления этих методов из проекта? W3C обсуждал эту тему в сообщении об ошибке 10671 . Майк Амундсен высказался в пользу этой поддержки:
Стоит прочитать весь его пост.
Том Уордроп также делает интересное замечание:
Иан Хиксон в конце концов исправил ошибку « Не исправлю» со следующим объяснением:
Однако это еще не конец истории! Проблема была закрыта в трекере ошибок W3C и перешла в трекер проблем рабочей группы HTML:
https://www.w3.org/html/wg/tracker/issues/195
На данный момент кажется, что главная причина, по которой эти методы не поддерживаются, заключается в том, что никто не нашел время для того, чтобы написать для него исчерпывающую спецификацию.
источник
GET и POST имеют четкое, нейтральное к содержанию обоснование. GET предназначен для получения содержимого URL-адреса таким образом, чтобы его можно было безопасно повторить и, возможно, кэшировать. POST - это что-то, что не безопасно повторять, спекулятивно выполнять или кэшировать.
Не было аналогичного обоснования для PUT или DELETE. Они оба полностью покрыты POST. Создание или уничтожение ресурса - это операции, которые небезопасно повторять, небезопасно выполнять спекулятивно и не должны кэшироваться. Для них не требуется никакой дополнительной специальной семантики.
Так что в принципе нет никакой пользы.
источник
POST
является идемпотентом, поэтому, когда вы нажимаете «назад» в своем браузере, он отображает некрасивую страницу, которая говорит, что форму необходимо отправить повторно. Однако , если бы он былPUT
, он мог бы безопасно переслатьPUT
запрос, чтобы отобразить любую страницу, которую вы должны получить. При условии, конечно, никто не испортит API, создав своего родаDELETE /resource/latest
.Эта проблема была поднята в 2010 году, поскольку ошибка 10671 предусматривает добавление поддержки PUT и DELETE в качестве методов формы .
У этой «особенности» было небольшое количество откатов и некоторая неуклюжесть, но в конечном итоге это обострилось из-за двух проблем в трекере ошибок рабочих групп:
Проблема ISSUE-196 привела к принятию консенсусом решения не вносить изменений в спецификацию, поскольку спецификация HTML в настоящее время не ограничивает обработку ответов на запросы POST. Я полагаю, что эта конкретная проблема возникла при попытке согласовать часто используемые шаблоны перенаправления POST и то, как серверы ReSTful часто предоставляют ответы 2xx с короткими сообщениями, а не с помощью чего-либо полезного для отображения в браузере.
Выпуск -195 был представлен на кафедре. Кэмерон Джонс выступил добровольно, написав предложение об изменении 18 января 2012 года, которое он представил, чтобы стать первым рабочим проектом 29 мая 2014 года. Проект будет проходить через процесс рекомендаций W3C .
Если повезет, это скоро станет рекомендацией W3C и будет реализовано поставщиками браузеров и станет большим шагом вперед в устранении блокировщиков для создания унифицированных, семантических и дружественных браузеру сервисов ReSTful. Я предполагаю, что это вызовет интересную эволюцию в шаблонах обслуживания. Джон Мур (Jon Moore) говорит о том, что API-интерфейсы Hypermedia заслуживают внимания, меня это заинтересовало, но они упали с первого же препятствия (вот этого).
источник
Насколько я понимаю, браузеры не знают, что делать после отправки PUT или DELETE. POST обычно перенаправляет на соответствующую страницу, но PUT и DELETE обычно этого не делают. Это делает их подходящими для вызова через ajax или нативную программу, но не из формы веб-браузера.
Я не могу сейчас это скрыть, но я помню, как читал один из списков рассылки html5, когда они обсуждали это.
источник
история
Я думаю, что стоит упомянуть о первом появлении html-форм в RFC1866 (раздел 8.1) . Здесь атрибут метода определяется следующим образом:
Дальнейшие объяснения находятся в Разделе 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).
источник
Просто выбрасываю дикие предположения, но, возможно, потому, что HTTP не очень хорошо справляется с управлением доступом в лучшие времена, и последнее, что всем нужно, - это еще больше способов для вредоносных URL-адресов скомпрометировать плохо защищенный веб-сайт и / или приложение.
HTTP не очень хороший протокол для передачи файлов, кроме загрузки с сервера на клиент. Используйте FTP - или еще лучше, SFTP.
источник
curl --request PUT http://A.B.c/index
Вопрос в том, почему вы можете получить доступ к этим командам через HTML.Get и post - это форматы передачи данных запроса.
Я полагаю, что вы спрашиваете о том, чтобы сделать отправку формы в RESTFUL сервис. Но не имеет смысла изменять стандарт http-запроса, чтобы сделать предположения целью http-запроса. Информация о цели, которую заполняет запрос, лучше всего обрабатывается в полях ввода.
Наличие адреса, get и post позволяет серверу правильно интерпретировать запрос и его входные значения. Оттуда входные значения позволяют вам делать открытые запросы к серверу и делать все, что вы хотите. Например, у вас может быть поле со значениями «положить» и «удалить»
источник