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

Für mich lag der Schlüssel zum Verständnis des Unterschieds darin zu verstehen, wer die ID definiert der Ressource:

Beispiel (mit einem Adressdienst)

POST (Server erstellt neue Ressource)

Client               Server/Adressen      // HINWEIS: keine ID im Anforderung
  |                                 |
  | --{POST Adressdaten}-->        |
  |                                 |
  | <--{201, erstellte Adressen/321} |      // HINWEIS: Ressourcen-ID in der Antwort
  |                                 |

PUT (Server setzt Daten der Ressource, erstellt sie bei Bedarf)

Client               Server/Adressen/321      // HINWEIS: *du* setzt die ID hier!
  |                                 |
  | --{PUT Adressdaten (zu 321)}-->|
  |                                 |
  | <--{201, erstellt }              |          // HINWEIS: Ressourcen-ID hier nicht erforderlich
  |                                 |

Es gibt viele großartige Antworten mit vielen Details unten, aber das half mir, auf den Punkt zu kommen.

Answer 2

Zusammenfassung

• Verwenden Sie PUT, um den Zustand der Ziel-Ressource mit dem in der Anforderung enthaltenen Zustand zu erstellen oder zu ersetzen. Dieser beabsichtigte Effekt ist standardisiert und idempotent, sodass Zwischenhändler informiert werden können, dass sie eine Anfrage im Falle eines Kommunikationsfehlers wiederholen können.
• Verwenden Sie andernfalls POST (einschließlich zum Erstellen oder Ersetzen des Zustands einer Ressource, die nicht die Zielressource ist). Der beabsichtigte Effekt ist nicht standardisiert, sodass Zwischenhändler keine Annahme treffen können.

Referenzen

Die neueste maßgebliche Beschreibung des semantischen Unterschieds zwischen den Anforderungsmethoden POST und PUT finden Sie in RFC 9110 (Roy Fielding, Mark Nottingham, Julian Reschke, 2022):

Der grundlegende Unterschied zwischen den Methoden POST und PUT wird durch die unterschiedliche Absicht für die enthaltene Repräsentation hervorgehoben. Die Zielressource in einer POST-Anforderung soll die enthaltene Repräsentation gemäß den eigenen Semantiken der Ressource verarbeiten, während die enthaltene Repräsentation in einer PUT-Anforderung als Ersetzen des Zustands der Zielressource definiert ist. Daher ist die Absicht von PUT idempotent und für Zwischenhändler sichtbar, obwohl der genaue Effekt nur vom Ursprungsserver bekannt ist.

Mit anderen Worten, der beabsichtigte Effekt von PUT ist standardisiert (Erstellen oder Ersetzen des Zustands der Ziel-Ressource mit dem in der Anforderung enthaltenen Zustand) und daher generisch für alle Zielressourcen, während der beabsichtigte Effekt von POST nicht standardisiert ist und daher spezifisch für jede Zielressource ist. Daher kann POST für alles verwendet werden, einschließlich für das Erreichen der beabsichtigten Effekte von PUT und anderen Anforderungsmethoden (GET, HEAD, DELETE, CONNECT, OPTIONS und TRACE).

Es wird jedoch empfohlen, immer die spezialisiertere Anforderungsmethode anstelle von POST zu verwenden, wenn dies möglich ist, da sie Zwischenhändlern mehr Informationen für die Automatisierung der Informationsabfrage bereitstellt (da GET, HEAD, OPTIONS und TRACE als sicher definiert sind), die Behandlung von Kommunikationsfehlern erleichtert (da GET, HEAD, PUT, DELETE, OPTIONS und TRACE als idempotent definiert sind) und die Cache-Leistung optimiert (da GET und HEAD als cacheable definiert sind), wie in It Is Okay to Use POST (Roy Fielding, 2009) erklärt wird:

POST wird nur zu einem Problem, wenn es in einer Situation verwendet wird, für die eine andere Methode ideal geeignet ist: z. B. die Abfrage von Informationen, die eine Repräsentation einer Ressource sein sollte (GET), die vollständige Ersetzung einer Repräsentation (PUT) oder eine der anderen standardisierten Methoden, die Zwischenhändlern wertvollere Informationen als "dies könnte etwas ändern" mitteilen. Die anderen Methoden sind für Zwischenhändler wertvoller, da sie etwas über die automatische Behandlung von Fehlern und das Optimieren des Verhaltens von Zwischenspeichern aussagen. POST hat diese Eigenschaften nicht, aber das bedeutet nicht, dass wir ohne ihn auskommen können. POST erfüllt viele nützliche Zwecke in HTTP, einschließlich des allgemeinen Zwecks von "diese Aktion ist es nicht wert, standardisiert zu werden".

Answer 3

Die Semantik soll unterschiedlich sein, in dem "PUT", wie "GET", idempotent sein soll - das heißt, du kannst dieselbe PUT-Anfrage mehrmals ausführen und das Ergebnis wird sein, als hättest du sie nur einmal ausgeführt.

Ich werde die Konventionen beschreiben, die meiner Meinung nach am weitesten verbreitet und am nützlichsten sind:

Wenn du eine Ressource an einer bestimmten URL speicherst, sollte sie dort gespeichert werden oder ähnliches.

Wenn du Informationen zu einer Ressource an einer bestimmten URL postest, postest du oft ein damit verbundenes Informationsstück an diese URL. Dies impliziert, dass die Ressource unter der URL bereits existiert.

Zum Beispiel, wenn du einen neuen Stream erstellen möchtest, kannst du ihn an eine bestimmte URL PUTen. Wenn du jedoch eine Nachricht an einen vorhandenen Stream posten möchtest, postest du an dessen URL.

Was die Änderung der Eigenschaften des Streams betrifft, kannst du das entweder mit PUT oder POST tun. Verwende "PUT" nur, wenn die Operation idempotent ist - ansonsten verwende POST.

Beachte jedoch, dass nicht alle modernen Browser HTTP-Verben außer GET oder POST unterstützen.

Answer 4

Die meiste Zeit wird man sie so verwenden:

• POST eines Elements in eine Sammlung
• PUT eines Elements identifiziert durch collection/:id

Zum Beispiel:

• POST /items
• PUT /items/1234

In beiden Fällen enthält der Anfrage-Body die Daten für das zu erstellende oder zu aktualisierende Element. Aus den Routennamen sollte offensichtlich sein, dass POST nicht idempotent ist (rufen Sie ihn 3 Mal auf, erstellt er 3 Objekte), PUT aber idempotent ist (rufen Sie ihn 3 Mal auf, ist das Ergebnis dasselbe). PUT wird oft für die "upsert" Operation (erstellen oder aktualisieren) verwendet, aber Sie können immer einen 404 Fehler zurückgeben, wenn Sie es nur verwenden wollen, um zu ändern.

Beachten Sie, dass POST ein neues Element in der Sammlung "erstellt" und PUT ein Element an einer bestimmten URL "ersetzt", jedoch ist es eine sehr häufige Praxis, PUT für partielle Änderungen zu verwenden, das heißt, es nur zum Aktualisieren vorhandener Ressourcen zu verwenden und nur die in dem Body enthaltenen Felder zu ändern (die anderen zu ignorieren). Technisch gesehen ist dies inkorrekt, wenn Sie ein REST-Purist sein wollen, sollte PUT die gesamte Ressource ersetzen und Sie sollten PATCH für die teilweise Aktualisierung verwenden. Mir persönlich ist es egal, solange das Verhalten klar und konsistent über alle Ihre API-Endpunkte ist.

Denken Sie daran, REST ist eine Reihe von Konventionen und Richtlinien, um Ihre API einfach zu halten. Wenn Sie mit einem komplizierten Workaround enden, nur um den "RESTvoll" Haken zu setzen, verfehlen Sie den Zweck ;)

Answer 5

Während es wahrscheinlich einen agnostischen Weg gibt, diese zu beschreiben, scheint es doch im Widerspruch zu verschiedenen Aussagen von Antworten auf Websites zu stehen.

Lassen Sie uns hier sehr klar und direkt sein. Wenn Sie ein .NET-Entwickler sind, der mit Web-API arbeitet, sind die Fakten (aus der Microsoft-API-Dokumentation), http://www.asp.net/web-api/overview/creating-web-apis/creating-a-web-api-that-supports-crud-operations:

1. PUT = UPDATE (/api/products/id)
2. MCSD-Prüfungen 2014 - UPDATE = PUT, es gibt **KEINE** mehreren Antworten für diese Frage, Punkt.

Sicher, Sie "können" "POST" zum Aktualisieren verwenden, aber halten Sie sich einfach an die Konventionen, die Ihr Framework für Sie festgelegt hat. In meinem Fall ist es .NET / Web-API, daher gilt PUT für UPDATE, es gibt keine Diskussion.

Ich hoffe, dies hilft allen Microsoft-Entwicklern, die alle Kommentare mit Amazon- und Sun/Java-Website-Links lesen.