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

Ich mag diesen Ratschlag, aus RFC 2616's Definition von PUT:

Der grundlegende Unterschied zwischen den POST- und PUT-Anfragen spiegelt sich in der unterschiedlichen Bedeutung des Request-URI wider. Die URI in einer POST-Anfrage identifiziert die Ressource, die die eingebettete Entität verarbeiten wird. Diese Ressource kann ein Datenakzeptanzprozess, ein Gateway zu einem anderen Protokoll oder eine separate Entität sein, die Annotationen akzeptiert. Im Gegensatz dazu identifiziert die URI in einer PUT-Anfrage die mit der Anfrage eingebettete Entität -- der Benutzeragent weiß, welche URI beabsichtigt ist, und der Server DARF NICHT versuchen, die Anfrage auf eine andere Ressource anzuwenden.

Dies stimmt mit dem anderen Rat hier überein, dass PUT am besten auf Ressourcen angewendet wird, die bereits einen Namen haben, und POST gut geeignet ist, um ein neues Objekt unter einer vorhandenen Ressource zu erstellen (und dem Server die Benennung zu überlassen).

Ich interpretiere dies und die Anforderungen an die Idempotenz bei PUT so:

• POST ist gut geeignet, um neue Objekte unter einer Sammlung zu erstellen (und die Erstellung muss nicht idempotent sein)
• PUT ist gut geeignet, um bestehende Objekte zu aktualisieren (und die Aktualisierung muss idempotent sein)
• POST kann auch für nicht-idempotente Aktualisierungen an bestehenden Objekten verwendet werden (insbesondere für die Änderung eines Teils eines Objekts ohne Angabe des gesamten Objekts - wenn man darüber nachdenkt, ist die Erstellung eines neuen Elements einer Sammlung tatsächlich ein Sonderfall dieser Art von Aktualisierung aus der Perspektive der Sammlung)
• PUT kann auch für die Erstellung verwendet werden, wenn und nur wenn der Client die Ressource benennen darf. Da REST-Clients jedoch keine Annahmen über die URL-Struktur treffen sollen, ist dies weniger im beabsichtigten Geist der Dinge.

Answer 2

Kurz gesagt:

PUT ist idempotent, bei dem der Ressourcenstatus gleich bleibt, wenn die gleiche Operation einmal oder mehrmals ausgeführt wird.

POST ist nicht idempotent, bei dem sich der Ressourcenstatus ändern kann, wenn die Operation mehrmals ausgeführt wird im Vergleich zu einer einzelnen Ausführung.

Analogie mit einer Datenbankabfrage

PUT kann man sich ähnlich vorstellen wie "UPDATE STUDENT SET address = "abc" WHERE id="123";

POST kann man sich etwas vorstellen wie "INSERT INTO STUDENT(name, address) VALUES ("abc", "xyzzz");

Die Studenten-ID wird automatisch generiert.

Bei PUT bleibt der Zustand der STUDENT-Tabelle unverändert, wenn die gleiche Abfrage mehrmals oder einmal ausgeführt wird.

Im Falle von POST werden bei mehrfacher Ausführung der gleichen Abfrage mehrere Studentendatensätze in der Datenbank erstellt und der Datenbankzustand ändert sich bei jeder Ausführung einer "INSERT"-Abfrage.

ANMERKUNG: PUT benötigt einen Ressourcenort (bereits vorhandene Ressource), auf den das Update angewendet werden soll, während POST das nicht erfordert. Daher ist intuitiv POST für die Erstellung einer neuen Ressource gedacht, während PUT für die Aktualisierung der bereits vorhandenen Ressource benötigt wird.

Manche mögen darauf kommen, dass Updates mit POST durchgeführt werden können. Es gibt keine strikte Regel, welche für Updates zu verwenden ist und welche für die Erstellung. Auch hier handelt es sich um Konventionen, und intuitiv neige ich zu der oben genannten Argumentation und folge ihr.

Answer 3

POST ist wie das Einwerfen eines Briefs in einen Briefkasten oder das Absenden einer E-Mail in eine E-Mail-Warteschlange. PUT ist vergleichbar damit, wenn man ein Objekt in ein Fach oder an einen bestimmten Platz im Regal legt (es hat eine bekannte Adresse).

Bei POST senden Sie an die Adresse der WARTESCHLANGE oder SAMMLUNG. Bei PUT legen Sie an die Adresse des ELEMENTS.

PUT ist idempotent. Sie können die Anfrage 100 Mal senden und es macht keinen Unterschied. POST ist nicht idempotent. Wenn Sie die Anfrage 100 Mal senden, erhalten Sie 100 E-Mails oder 100 Briefe in Ihrem Postfach.

Ein allgemeine Regel: Wenn Sie die ID oder den Namen des Elements kennen, verwenden Sie PUT. Wenn Sie möchten, dass die ID oder der Name des Elements vom Empfänger zugewiesen wird, verwenden Sie POST.

Answer 4

Kurze Antwort:

Eine einfache Faustregel: Verwenden Sie POST zum Erstellen, verwenden Sie PUT zum Aktualisieren.

Lange Antwort:

POST:

• POST wird verwendet, um Daten an den Server zu senden.
• Nützlich, wenn die URL des Ressourcen unbekannt ist.

PUT:

• PUT wird verwendet, um den Zustand an den Server zu übertragen.
• Nützlich, wenn die URL einer Ressource bekannt ist.

Noch längere Antwort:

Um dies zu verstehen, müssen wir uns fragen, warum PUT erforderlich war, welche Probleme PUT lösen wollte, die POST nicht konnte.

Aus der Sicht der REST-Architektur spielt das keine Rolle. Wir hätten auch ohne PUT leben können. Aber aus der Sicht eines Client-Entwicklers wurde sein/ihr Leben dadurch erheblich vereinfacht.

Vor PUT konnten die Clients nicht direkt die URL kennen, die der Server generiert hat, oder ob der Server überhaupt eine generiert hat oder ob die zu sendenden Daten bereits aktualisiert wurden oder nicht. PUT befreite den Entwickler von all diesen Kopfschmerzen. PUT ist idempotent, PUT behandelt Wettlaufbedingungen und PUT lässt den Client die URL wählen.

Answer 5

Neue Antwort (jetzt, da ich REST besser verstehe):

PUT ist lediglich eine Aussage darüber, welchen Inhalt der Service ab jetzt verwenden soll, um Repräsentationen der vom Client identifizierten Ressource darzustellen; POST ist eine Aussage darüber, welchen Inhalt der Service ab jetzt enthalten soll (möglicherweise dupliziert), aber es liegt am Server, wie dieser Inhalt identifiziert wird.

PUT x (wenn x eine Ressource identifiziert): "Ersetze den Inhalt der Ressource, die durch x identifiziert wird, durch meinen Inhalt."

PUT x (wenn x keine Ressource identifiziert): "Erstelle eine neue Ressource, die meinen Inhalt enthält, und verwende x, um sie zu identifizieren."

POST x: "Speichere meinen Inhalt und gib mir einen Bezeichner, den ich verwenden kann, um eine Ressource (alt oder neu) zu identifizieren, die diesen Inhalt enthält (möglicherweise zusammen mit anderem Inhalt). Die genannte Ressource sollte identisch oder untergeordnet sein zu der, die x identifiziert." "Ressource von y ist untergeordnet zu Ressource von x" wird typischerweise, aber nicht unbedingt, umgesetzt, indem y ein Unterverzeichnis von x wird (zum Beispiel x = /foo und y = /foo/bar) und die Repräsentation(en) der Ressource von x modifiziert werden, um die Existenz einer neuen Ressource widerzuspiegeln, zum Beispiel mit einem Hyperlink zur Ressource von y und einigen Metadaten. Letzteres ist für ein gutes Design wirklich wesentlich, da URLs in REST opak sind - Sie sollen stattdessen Hypermedia verwenden, anstatt auf der Client-Seite URL-Konstruktion zu verwenden, um den Dienst zu durchlaufen.

In REST gibt es keine Ressource, die "Inhalte" enthält. Ich bezeichne als "Inhalt" Daten, die der Service verwendet, um Repräsentationen konsistent darzustellen. Es besteht typischerweise aus einigen zugehörigen Zeilen in einer Datenbank oder einer Datei (zum Beispiel einer Bilddatei). Es liegt am Service, den Inhalt des Benutzers in etwas umzuwandeln, das der Service verwenden kann, zum Beispiel die Umwandlung eines JSON-Payloads in SQL-Anweisungen.

Ursprüngliche Antwort (vielleicht einfacher zu lesen):

PUT /etwas (wenn /etwas bereits existiert): "Nimm alles, was du bei /etwas hast, und ersetze es durch das, was ich dir gebe."

PUT /etwas (wenn /etwas noch nicht existiert): "Nimm, was ich dir gebe, und platziere es bei /etwas."

POST /etwas: "Nimm, was ich dir gebe, und platziere es an beliebiger Stelle unter /etwas, solange du mir die URL gibst, wenn du fertig bist."