Was ist der Unterschied zwischen POST und PUT in HTTP?

Question

Hintergrundinformationenanalyse:

Gemäß RFC 2616, § 9.5 wird POST verwendet, um eine Ressource zu erstellen:

Die POST-Methode wird verwendet, um zu fordern, dass der Ursprungsserver die im Request eingebettete Entität als neue untergeordnete Ressource der im Request-Zeilen-URI identifizierten Ressource akzeptiert.

Gemäß RFC 2616, § 9.6 wird PUT verwendet, um eine Ressource zu erstellen oder zu ersetzen:

Die PUT-Methode fordert, dass die eingebettete Entität unter dem bereitgestellten Request-URI gespeichert wird. Wenn der Request-URI auf eine bereits vorhandene Ressource verweist, sollte die eingebettete Entität als modifizierte Version derjenigen angesehen werden, die auf dem Ursprungsserver liegt. Wenn der Request-URI nicht auf eine vorhandene Ressource zeigt und dieser URI als neue Ressource vom anfordernden User-Agent definiert werden kann, kann der Ursprungsserver die Ressource mit diesem URI erstellen.

Meine Frage:

Also, welche HTTP-Methode sollte verwendet werden, um eine Ressource zu erstellen? Oder sollten beide unterstützt werden?

Answer 1

Ruby on Rails 4.0 wird die 'PATCH'-Methode anstelle von PUT zur Durchführung von teilweisen Aktualisierungen verwenden.

RFC 5789 sagt seit 1995 über PATCH:

Ein neuer Methode ist notwendig, um die Interoperabilität zu verbessern und Fehler zu vermeiden. Die PUT-Methode ist bereits definiert, um eine Ressource mit einem vollständig neuen Body zu überschreiben und kann nicht wiederverwendet werden, um partielle Änderungen vorzunehmen. Andernfalls könnten Proxies und Caches, und sogar Clients und Server, über das Ergebnis des Vorgangs verwirrt werden. POST wird bereits verwendet, jedoch ohne breite Interoperabilität (zum Beispiel gibt es keine standardisierte Möglichkeit, die Unterstützung für Patch-Formate zu entdecken). PATCH wurde bereits in früheren HTTP-Spezifikationen erwähnt, aber nicht vollständig definiert.

"Edge Rails: PATCH ist die neue primäre HTTP-Methode für Aktualisierungen" erklärt es.

Answer 2

Neben den von anderen vorgeschlagenen Unterschieden möchte ich noch einen hinzufügen.

Im POST-Verfahren können Sie Body-Parameter in form-data senden.

Im PUT-Verfahren müssen Sie Body-Parameter in x-www-form-urlencoded senden.

Header Content-Type:application/x-www-form-urlencoded

Basierend darauf können Sie keine Dateien oder mehrteilige Daten im PUT-Verfahren senden.

BEARBEITEN

Der Inhaltstyp "application/x-www-form-urlencoded" ist ineffizient für den Versand großer Mengen binärer Daten oder Texte mit Nicht-ASCII-Zeichen. Der Inhaltstyp "multipart/form-data" sollte für das Übermitteln von Formularen verwendet werden, die Dateien, Nicht-ASCII-Daten und binäre Daten enthalten.

Dies bedeutet, dass Sie für das Übermitteln von

Dateien, Nicht-ASCII-Daten und binären Daten

das POST-Verfahren verwenden sollten.

Answer 3

Riskieren wir, das zu wiederholen, was bereits gesagt wurde, so scheint es wichtig zu sein, sich daran zu erinnern, dass PUT impliziert, dass der Client steuert, was die URL letztendlich sein wird, bei der Erstellung eines Ressourcen. Ein Teil der Wahl zwischen PUT und POST wird also davon abhängen, wie sehr man dem Client vertrauen kann, korrekte, normalisierte _URL_s bereitzustellen, die mit Ihrem URL-Schema zusammenhängen.

Wenn man dem Client nicht vollständig vertrauen kann, das Richtige zu tun, wäre es angemessener, POST zu verwenden, um ein neues Element zu erstellen und dann die URL in der Antwort an den Client zurückzusenden.

Answer 4

Auf eine sehr einfache Weise nehme ich das Beispiel der Facebook-Timeline.

Fall 1: Wenn Sie etwas auf Ihrer Timeline veröffentlichen, handelt es sich um einen frischen Eintrag. In diesem Fall wird die POST-Methode verwendet, da die POST-Methode nicht idempotent ist.

Fall 2: Wenn Ihr Freund zum ersten Mal auf Ihren Beitrag kommentiert, wird auch ein neuer Eintrag in der Datenbank erstellt, daher wird die POST-Methode verwendet.

Fall 3: Wenn Ihr Freund seinen Kommentar bearbeitet, haben sie in diesem Fall eine Kommentar-ID, also aktualisieren sie einen bestehenden Kommentar anstelle eines neuen Eintrags in der Datenbank zu erstellen. Für diese Art von Operation wird daher die PUT-Methode verwendet, da sie idempotent ist.

Verwenden Sie in einer einzigen Zeile POST, um einen neuen Eintrag in der Datenbank hinzuzufügen, und PUT, um etwas in der Datenbank zu aktualisieren.

Answer 5

Die wichtigste Überlegung ist Zuverlässigkeit. Wenn eine POST-Nachricht verloren geht, ist der Zustand des Systems undefiniert. Eine automatische Wiederherstellung ist unmöglich. Bei PUT-Nachrichten ist der Zustand nur bis zum ersten erfolgreichen Wiederholungsversuch undefiniert.

Es ist beispielsweise möglicherweise keine gute Idee, Kreditkartentransaktionen mit POST zu erstellen.

Wenn Sie zufällig automatisch generierte URIs für Ihre Ressourcen haben, können Sie PUT dennoch verwenden, indem Sie dem Client eine generierte URI (die auf eine leere Ressource verweist) übergeben.

Weitere Überlegungen:

• POST macht gespeicherte Kopien der gesamten enthaltenen Ressource ungültig (bessere Konsistenz)
• ANTWORTEN auf PUT sind nicht zwischenspeicherbar, während POST-Antworten zwischenspeicherbar sind (erfordern Content-Location und Ablauf)
• PUT wird von z.B. Java ME, älteren Browsern und Firewalls weniger unterstützt