Was ist der Unterschied zwischen einer POST und einer PUT HTTP REQUEST?

Question

Beide scheinen Daten an den Server im Körper zu senden, was unterscheidet sie also?

Answer 1

Eigentlich gibt es außer dem Titel keinen Unterschied. Es gibt tatsächlich einen grundlegenden Unterschied zwischen GET und den anderen. Bei einer "GET"-Request-Methode senden Sie die Daten in der URL-Adresszeile, die zunächst durch ein Fragezeichen und dann durch ein &-Zeichen getrennt sind.

Bei einer "POST"-Request-Methode können Sie jedoch keine Daten über die URL übergeben, sondern müssen die Daten als Objekt im so genannten "Body" der Anfrage übergeben. Auf der Serverseite muss man dann den Body des empfangenen Inhalts auslesen, um die gesendeten Daten zu erhalten. Auf der anderen Seite gibt es aber keine Möglichkeit, Inhalte im Body zu senden, wenn man eine "GET"-Request sendet.

Die Behauptung, dass "GET" nur zum Abrufen von Daten und "POST" zum Einstellen von Daten dient, ist absolut falsch. Niemand kann Sie daran hindern, neue Inhalte zu erstellen, bestehende Inhalte zu löschen, bestehende Inhalte zu bearbeiten oder was auch immer im Backend zu tun, basierend auf den Daten, die durch die "GET"-Anfrage oder die "POST"-Anfrage gesendet werden. Und niemand kann Sie daran hindern, das Backend so zu programmieren, dass der Client mit einem "POST"-Request Daten anfordert.

Bei einer Anfrage, egal welche Methode Sie verwenden, rufen Sie eine URL auf und senden oder senden nicht einige Daten, um anzugeben, welche Informationen Sie an den Server weitergeben wollen, um Ihre Anfrage zu bearbeiten, und dann erhält der Client eine Antwort vom Server. Die Daten können alles enthalten, was Sie senden wollen, das Backend kann mit den Daten machen, was es will, und die Antwort kann alle Informationen enthalten, die Sie dort hineinlegen wollen.

Es gibt nur diese beiden GRUNDMETHODEN: GET und POST. Aber es ist ihre Struktur, die sie unterscheidet, und nicht das, was Sie im Backend kodieren. Im Backend können Sie mit den empfangenen Daten programmieren, was Sie wollen. Aber bei der "POST"-Anforderung müssen Sie die Daten im Body und nicht in der URL-Adresszeile senden/abrufen, und bei einer "GET"-Anforderung müssen Sie die Daten in der URL-Adresszeile und nicht im Body senden/abrufen. Das war's schon.

Alle anderen Methoden, wie "PUT", "DELETE" usw., haben die gleiche Struktur wie "POST".

Die POST-Methode wird vor allem dann verwendet, wenn man den Inhalt etwas verstecken möchte, denn was auch immer man in die URL-Adresszeile schreibt, wird im Cache gespeichert und eine GET-Methode ist dasselbe wie das Schreiben einer URL-Adresszeile mit Daten. Wenn Sie also sensible Daten senden wollen, die nicht unbedingt aus Benutzername und Passwort bestehen, sondern z.B. aus Kennungen oder Hashes, die nicht in der URL-Adresszeile angezeigt werden sollen, dann sollten Sie die POST-Methode verwenden.

Auch die Länge der URL-Adresszeile ist auf 1024 Zeichen begrenzt, während die "POST"-Methode nicht eingeschränkt ist. Wenn Sie also eine größere Menge an Daten haben, können Sie diese möglicherweise nicht mit einer GET-Anfrage senden, sondern müssen die POST-Anfrage verwenden. Dies ist also ein weiterer Pluspunkt für den POST-Request.

Aber der Umgang mit der GET-Anfrage ist viel einfacher, wenn man keinen komplizierten Text zu senden hat. Ansonsten, und das ist ein weiterer Pluspunkt für die POST-Methode, muss man bei der GET-Methode den Text url-encodieren, um einige Symbole innerhalb des Textes oder sogar Leerzeichen senden zu können. Bei der POST-Methode hingegen gibt es keine Einschränkungen, und der Inhalt muss in keiner Weise verändert oder manipuliert werden.

Answer 2

Zusammenfassung

• Utilice PUT zu erstellen oder zu ersetzen, den Zustand der Ziel Ressource mit dem Zustand, der durch die in der Anfrage enthaltene Darstellung definiert ist. Diese genormt die beabsichtigte Wirkung ist idempotent Damit wird den Vermittlern mitgeteilt, dass sie im Falle eines Kommunikationsfehlers eine Anfrage wiederholen können.
• Utilice POST auf andere Weise (auch um den Zustand einer anderen Ressource als der Zielressource zu erzeugen oder zu ersetzen). Die beabsichtigte Wirkung ist nicht genormt Die Vermittler können sich also nicht auf eine universelle Eigenschaft berufen.

Referenzen

Die letzte maßgebliche Beschreibung des semantischen Unterschieds zwischen den POST et PUT Methoden der Anfrage ist in RFC 7231 (Roy Fielding, Julian Reschke, 2014):

Der grundlegende Unterschied zwischen der POST et PUT Methoden wird durch die unterschiedliche Absicht für die beigefügte Darstellung hervorgehoben. Die Zielressource in einer POST Anfrage soll die eingeschlossene Darstellung gemäß der eigenen Semantik der Ressource behandelt werden, während die eingeschlossene Darstellung in einer PUT Anforderung ist definiert als Ersetzung des Zustands der Zielressource. Daher ist die Absicht von PUT ist idempotent und für die Vermittler sichtbar, auch wenn die genaue Wirkung nur dem Ursprungsserver bekannt ist.

Mit anderen Worten, die beabsichtigte Wirkung von PUT es genormt (Erstellen oder Ersetzen des Status der Ziel Ressource mit dem Zustand, der durch die in der Anfrage enthaltene Darstellung definiert ist) und ist somit für alle Zielressourcen gleich, während die beabsichtigte Wirkung von POST es nicht genormt und ist somit spezifisch für jede Zielressource. Daher POST kann für alles verwendet werden, auch für die Erreichung der beabsichtigten Wirkungen von PUT und andere Anforderungsmethoden ( GET , HEAD , DELETE , CONNECT , OPTIONS und TRACE ).

Es wird jedoch empfohlen, immer die speziellere Anfragemethode zu verwenden, anstatt POST wenn sie anwendbar ist, weil sie den Vermittlern mehr Informationen zur Verfügung stellt, um den Informationsabruf zu automatisieren (da GET , HEAD , OPTIONS und TRACE sind definiert als sicher ), Behandlung von Kommunikationsfehlern (da GET , HEAD , PUT , DELETE , OPTIONS und TRACE sind definiert als idempotent ), und die Optimierung der Cache-Leistung (da GET et HEAD sind definiert als cachefähig ), wie erklärt in Es ist in Ordnung, POST zu verwenden (Roy Fielding, 2009):

POST wird nur dann zum Problem, wenn sie in einer Situation verwendet wird, für die eine andere Methode ideal geeignet ist: z. B. beim Abrufen von Informationen, die eine Darstellung einer Ressource sein sollten ( GET ), vollständige Ersetzung einer Darstellung ( PUT ) oder eine der anderen standardisierten Methoden, die den Vermittlern etwas Wertvolleres sagen als "das könnte etwas ändern". Die anderen Methoden sind für Vermittler wertvoller, weil sie etwas darüber aussagen, wie Fehler automatisch behandelt werden können und wie Zwischencaches ihr Verhalten optimieren können. POST hat diese Eigenschaften nicht, aber das bedeutet nicht, dass wir ohne sie leben können. POST dient in HTTP vielen nützlichen Zwecken, darunter auch dem allgemeinen Zweck "diese Aktion ist es nicht wert, standardisiert zu werden".

Answer 3

Sowohl PUT als auch POST sind Rest-Methoden.

PUT - Wenn wir die gleiche Anfrage zweimal mit PUT stellen und beide Male die gleichen Parameter verwenden, hat die zweite Anfrage keine Auswirkungen. Aus diesem Grund wird PUT im Allgemeinen für das Update-Szenario verwendet. Ein mehrfacher Aufruf von Update mit denselben Parametern bewirkt nicht mehr als der erste Aufruf, daher ist PUT idempotent.

POST ist nicht idempotent, z.B. wird Create zwei separate Einträge im Ziel erstellen, daher ist es nicht idempotent, CREATE wird häufig in POST verwendet.

Wenn Sie denselben Aufruf mit POST und denselben Parametern durchführen, werden zwei verschiedene Dinge geschehen. Deshalb wird POST üblicherweise für das Szenario "Erstellen" verwendet.

Answer 4

Post und Put werden hauptsächlich zum Posten von Daten und zur Aktualisierung von Daten verwendet. Aber Sie können das Gleiche mit Post-Anfrage nur tun.