it-swarm.dev

Warum gibt es in HTML-Formularen keine PUT- und DELETE-Methoden?

HTML4/XHTML1 erlaubt nur GET und POST in Formularen, jetzt scheint HTML5 dasselbe zu tun. Es gibt ein Vorschlag zum Hinzufügen diese beiden, aber das tut es nicht scheinen an Bedeutung zu gewinnen. Was waren die technischen oder politischen Gründe dafür, PUT und DELETE nicht in den HTML5-Spezifikationsentwurf aufzunehmen?

281
FilipK

Das ist eine faszinierende Frage. Die anderen Antworten hier sind alle spekulativ und in einigen Fällen völlig falsch. Anstatt meine Meinung hier zu schreiben, habe ich tatsächlich einige Nachforschungen angestellt und Originalquellen gefunden, in denen diskutiert wird, warum löschen und put Nicht Teil des HTML5-Formularstandards sind.

Wie sich herausstellte, waren diese Methoden waren in mehrere, frühe HTML5-Entwürfe (!) Enthalten, wurden aber später in nachfolgende Entwürfe entfernt . Mozilla hatte dies tatsächlich implementiert in einer Firefox-Beta auch.

Was war der Grund, diese Methoden aus dem Entwurf zu entfernen? Das W3C hat dieses Thema in Fehlerbericht 10671 besprochen. Mike Amundsen sprach sich für diese Unterstützung aus:

Das Ausführen von PUT und DELETE zum Ändern von Ressourcen auf dem Origin-Server ist für moderne Webbrowser mit dem XmlHttpRequest-Objekt unkompliziert. Für nicht geschriebene Browser-Interaktionen ist dies nicht so einfach. [...]

Dieses Muster wird so oft benötigt, dass mehrere häufig verwendete Webframeworks/-bibliotheken eine "integrierte" Problemumgehung erstellt haben. [...]

Weitere Überlegungen:

  • Die Verwendung von POST als Tunnel anstelle von PUT/DELETE kann zu Caching-Fehlanpassungen führen (z. B. POST Antworten sind zwischenspeicherbar , PUT-Antworten sind nicht (6), DELETE-Antworten sind nicht (7))
  • Die Verwendung einer nicht-idempotenten Methode (POST) zum Ausführen einer idempotenten Operation (PUT/DELETE) erschwert die Wiederherstellung aufgrund von Netzwerkfehlern (z. B. "Ist es sicher, diese Aktion zu wiederholen?").
  • [...]

Es lohnt sich, seinen gesamten Beitrag zu lesen.

Tom Wardrop macht auch einen interessanten Punkt:

HTML ist untrennbar mit HTTP verbunden. HTML ist die Benutzeroberfläche von HTTP. Es ist daher automatisch fraglich, warum HTML nicht alle relevanten Methoden in der HTTP-Spezifikation unterstützt. Warum können Maschinen Ressourcen PUTEN und LÖSCHEN, Menschen jedoch nicht? [...]

Es ist widersprüchlich, dass HTML zwar große Anstrengungen unternimmt, um ein semantisches Markup sicherzustellen, aber bisher keine derartigen Anstrengungen unternommen hat, um semantische HTTP-Anforderungen sicherzustellen.

Der Fehler wurde schließlich von Ian Hickson als Won't Fix mit der folgenden Begründung geschlossen:

PUT als Formularmethode macht keinen Sinn, Sie möchten keine Formularnutzdaten PUT. LÖSCHEN macht nur Sinn, wenn keine Nutzlast vorhanden ist, daher macht es auch bei Formularen wenig Sinn.

Dies ist jedoch nicht das Ende der Geschichte! Das Problem wurde im W3C-Bug-Tracker geschlossen und eskaliert Zum Issue-Tracker der HTML-Arbeitsgruppe:

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

An diesem Punkt scheint der Hauptgrund, warum diese Methoden nicht unterstützt werden, einfach darin zu liegen, dass sich niemand die Zeit genommen hat, eine umfassende Spezifikation dafür zu schreiben.

370
Mark E. Haase

Dies wurde 2010 als Bug 10671 ausgelöst. Erwägen Sie, Unterstützung für PUT und DELETE als Formularmethoden hinzuzufügen .

Es gab ein moderates Maß an Pushback für dieses "Feature" und etwas Unbeholfenheit, aber schließlich wurde dies als zwei Probleme im Bug-Tracker der Arbeitsgruppen eskaliert:

Das Problem ISSUE-196 führte zu einer Konsensentscheidung, keine Änderung an der Spezifikation vorzunehmen, da die HTML-Spezifikation derzeit nicht einschränkt, wie auf POST Anfragen werden bearbeitet. Ich glaube, dieses spezielle Problem wurde beim Versuch aufgeworfen, POST häufig verwendete Umleitungsmuster miteinander in Einklang zu bringen, und wie ReSTful-Server häufig 2xx-Antworten mit Kurznachrichten bereitstellen, anstatt etwas Nützliches, das in einem Browser gerendert werden kann.

Die Ausgabe AUSGABE-195 wurde den Lehrstühlen vorgestellt. Cameron Jones hat sich am 18. Januar 2012 freiwillig gemeldet, um einen Änderungsvorschlag zu verfassen, den er am 29. Mai 2014 als ersten Arbeitsentwurf vorlegte. Der Entwurf durchläuft den W3C-Empfehlungsprozess .

Mit etwas Glück wird dies bald zu einer W3C-Empfehlung und wird von Browser-Anbietern implementiert. Dies wäre ein großer Fortschritt beim Entfernen der Blocker, um einheitliche, semantische und browserfreundliche ReSTful-Dienste zu erstellen. Ich stelle mir vor, dass dies spark eine interessante Entwicklung der Servicemuster bewirken wird. Es gibt einen guten Vortrag von Jon Moore - Hypermedia APIs , die es wert sind, gesehen zu werden. Dies hat mein Interesse geweckt, ist aber bei der ersten Hürde (dieser) gefallen.

13

GET und POST haben eine klare inhaltsneutrale Begründung. GET besteht darin, den Inhalt einer URL auf eine Weise abzurufen, die sicher wiederholt und möglicherweise zwischengespeichert werden kann. POST = soll etwas auf eine Weise tun, die nicht sicher wiederholt, spekulativ ausgeführt oder zwischengespeichert werden kann.

Es gab keine ähnliche Begründung für PUT oder DELETE. Sie sind beide vollständig von POST abgedeckt. Das Erstellen oder Zerstören einer Ressource sind Vorgänge, deren Wiederholung nicht sicher ist, deren spekulative Ausführung nicht sicher ist und die nicht zwischengespeichert werden sollten. Für sie ist keine zusätzliche spezielle Semantik erforderlich.

Grundsätzlich gibt es also keinen Vorteil.

12
David Schwartz

Ich verstehe, dass Browser nicht wissen, was sie tun sollen, wenn sie einen PUT oder einen DELETE senden. A POST leitet normalerweise zu einer geeigneten Seite um, PUT und DELETE jedoch normalerweise nicht. Dies macht sie für den Aufruf über Ajax oder ein natives Programm geeignet, jedoch nicht über ein Webbrowser-Formular.

Ich kann es momentan nicht behindern, aber ich erinnere mich, dass ich eine der HTML5-Mailinglisten gelesen habe, als sie darüber diskutierten.

5
maxpolun

Geschichte

Ich denke, es ist erwähnenswert, dass HTML-Formulare zum ersten Mal in RFC1866 (Abschnitt 8.1) erscheinen. Hier ist das Methodenattribut wie folgt definiert:

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".

Weitere Erläuterungen finden Sie in Abschnitt 8.2.2 - GET und Abschnitt 8.2.3 - POST

Beachten Sie, dass HTML 2.0 (Nov. 1995) angegeben wurde vorherHTTP 1. (Mai 1996). Daher verwendeten alle HTTP nur mit GET (ab HTTP 0.9) oder mit der Erweiterung POST. Es wurden jedoch nur wenige Webserver PUT und DELETE unterstützt (wie im HTTP 1.0-Anhang angegeben).

Gedanken

Wenn Sie darüber nachdenken, wie sich Berners-Lees Entwicklung des Semantic Web hätte entwickeln können, scheint es klar, dass es von tatsächlichen Problemen zu einem allgemeinen Konzept übergegangen ist. Zuerst wollte er Dokumente teilen. Deshalb brauchte er Markup. Dann wollte er Datenbanken nach Inhalten abfragen, also brauchte er Formulare. Dann wollte er neue Daten in die Datenbank stellen. Also benutzte er Formulare mit GET und POST. Danach hat er möglicherweise erkannt, dass Sie jede CRUD-Operation für Daten von Remote ausführen können. Daher wurde HTTP erweitert, jedoch niemals HTML, da es zu spät war (nur wenige Server unterstützten die neuen CRUD-Operationen).

5
schmijos