Чому на формах HTML не існує методів PUT і DELETE?

HTML4 / XHTML1 дозволяє лише GET і POST у формах, тепер, схоже, HTML5 зробить те саме. Є пропозиція додати ці два, але, схоже, це не набирає тяги. Які технічні чи політичні причини не включали PUT і DELETE в проект специфікації HTML5?

Це захоплююче питання. Інші відповіді тут є умоглядними, а в деяких випадках невірними. Замість того, щоб писати свою думку тут, я фактично провів деякі дослідження та знайшов оригінальні джерела, які обговорюють, чому видалення та розміщення не є частиною стандарту форми 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. Чому машини можуть PUT і DELETE використовувати ресурси, а людина не може? [...]

Суперечливо, що, хоча HTML намагається забезпечити семантичну розмітку, він до цього часу не докладав таких зусиль для забезпечення семантичних запитів HTTP.

Помилка була врешті-решт закрита, оскільки не виправлено Ian Hickson, з наступним обґрунтуванням:

PUT як метод форми не має сенсу, вам не хотілося б PUT форми корисного навантаження. DELETE має сенс лише якщо немає корисного навантаження, тому це не має великого сенсу і для форм.

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

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

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

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

Не було подібних обґрунтувань для PUT або DELETE. Вони обидва повністю охоплені POST. Створення або знищення ресурсу - це операції, які не є безпечними для повторення, не безпечні для спекулятивного виконання і не повинні кешуватися. Для них не потрібні додаткові спеціальні семантики.

Так що в основному користі немає.

Це було піднято в 2010 році, оскільки помилка 10671 розглядає можливість додавання підтримки PUT і DELETE як методів форми .

Для цієї "функції" була відмітна кількість відхилень та деяка обтяженість, але в кінцевому підсумку це було розширено як два питання у програмі пошуку помилок Робочих груп:

• ВИПУСК-195: Покращення генерування запитів http із форм
• ISSUE-196: Визначте поведінку обробки відповіді агентом користувача

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

Випуск ISSUE-195 був представлений кріслами. Камерон Джонс 18 січня 2012 року подав заяву про зміну, написавши пропозицію про зміну 18 січня 2012 року, яку він подав, щоб стати першим робочим проектом 29 травня 2014 року. Проект буде проходити через процес рекомендацій W3C .

За будь-якої удачі, це незабаром стане рекомендацією W3C і буде впроваджено постачальниками браузерів, і це буде чудовим кроком вперед у видаленні блокаторів для створення уніфікованих, семантичних та зручних для браузера послуг ReSTful. Я думаю, це призведе до цікавої еволюції в моделях обслуговування. Є хороша розмова Джона Мура - програми Hypermedia API, які варто переглянути, це зацікавило мене, але впало при першій перешкоді (цій).

Я розумію, що браузери не знають, що робити, коли вони надсилають PUT або DELETE. POST зазвичай переспрямовується на відповідну сторінку, але PUT і DELETE зазвичай не роблять. Це робить їх доречними для дзвінків через ajax або нативну програму, але не з форми веб-браузера.

Я зараз не можу перешкодити цьому, але пам’ятаю, що читав один із списків розсилки html5, коли вони обговорювали це.

Історія

Я думаю, що варто згадати першу появу 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-операції).

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

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

Отримати і відправити - це формати передачі даних запиту.

Я припускаю, що ви запитуєте про те, щоб зробити форму надсиланням у ПОСЛУГУ службу. Але не має сенсу змінювати стандарт запиту http, щоб робити припущення, призначенням http запиту. Інформація про мету, яку заповнює запит, найкраще обробляється у полях введення.

Наявлення адреси та отримання та публікації дозволяє серверу правильно інтерпретувати запит та його вхідні значення. Звідти вхідні значення дозволяють робити запити на сервер із відкритим контентом і робити все, що завгодно. Наприклад, ви можете мати поле, значення якого "поставити" та "видалити"