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

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

HTTP PUT:

PUT legt eine Datei oder Ressource an einem bestimmten URI und genau an diesem URI ab. Wenn sich an dieser URI bereits eine Datei oder Ressource befindet, ersetzt PUT diese Datei oder Ressource. Wenn dort keine Datei oder Ressource vorhanden ist, erstellt PUT eine. PUT ist idempotent , aber paradoxerweise können PUT-Antworten nicht zwischengespeichert werden.

HTTP 1.1-RFC-Speicherort für PUT

HTTP POST:

POST sendet Daten an einen bestimmten URI und erwartet, dass die Ressource an diesem URI die Anforderung verarbeitet. Der Webserver kann zu diesem Zeitpunkt festlegen, was mit den Daten im Kontext der angegebenen Ressource geschehen soll. Die POST-Methode ist nicht idempotent , POST-Antworten können jedoch zwischengespeichert werden , solange der Server die entsprechenden Cache-Control- und Expires-Header festlegt.

Der offizielle HTTP-RFC gibt POST wie folgt an:

• Anmerkung zu vorhandenen Ressourcen;
• Senden einer Nachricht an ein Schwarzes Brett, eine Newsgroup, eine Mailingliste oder eine ähnliche Gruppe von Artikeln;
• Bereitstellen eines Datenblocks, z. B. des Ergebnisses des Absendens eines Formulars, für einen Datenverarbeitungsprozess;
• Erweitern einer Datenbank durch Anhängen.

HTTP 1.1-RFC-Speicherort für POST

Unterschied zwischen POST und PUT:

Der RFC selbst erklärt den Kernunterschied:

Der grundlegende Unterschied zwischen den POST- und PUT-Anforderungen spiegelt sich in der unterschiedlichen Bedeutung des Anforderungs-URI wider. Der URI in einer POST-Anforderung gibt die Ressource an, die die eingeschlossene Entität verarbeitet. Diese Ressource kann ein Datenakzeptanzprozess, ein Gateway zu einem anderen Protokoll oder eine separate Entität sein, die Anmerkungen akzeptiert. Im Gegensatz dazu identifiziert der URI in einer PUT-Anforderung die der Anforderung beigefügte Entität. Der Benutzeragent weiß, welcher URI beabsichtigt ist, und der Server darf NICHT versuchen, die Anforderung auf eine andere Ressource anzuwenden. Wenn der Server möchte, dass die Anforderung auf einen anderen URI angewendet wird, MUSS er eine 301-Antwort (permanent verschoben) senden. Der Benutzeragent kann dann selbst entscheiden, ob die Anforderung umgeleitet werden soll oder nicht.

Zusätzlich und etwas präziser, RFC 7231 Abschnitt 4.3.4 PUT- Zustände (Hervorhebung hinzugefügt),

4.3.4. STELLEN

Die PUT-Methode fordert an, dass der Status der Zielressource createdoder replacedder Status ist, der durch die in der Nutzlast der Anforderungsnachricht enthaltene Darstellung definiert ist.

Mit der richtigen Methode, unabhängig davon:

Ein Vorteil von REST ROA gegenüber SOAP besteht darin, dass bei Verwendung von HTTP REST ROA die ordnungsgemäße Verwendung der HTTP-Verben / -Methoden gefördert wird. So würden Sie beispielsweise PUT nur verwenden, wenn Sie eine Ressource genau an diesem Ort erstellen möchten. Und Sie würden niemals GET verwenden, um eine Ressource zu erstellen oder zu ändern.

Nur Semantik.

Ein HTTP PUTsoll den Hauptteil der Anforderung akzeptieren und diesen dann in der vom URI angegebenen Ressource speichern.

Ein HTTP POSTist allgemeiner. Es soll eine Aktion auf dem Server auslösen. Diese Aktion kann darin bestehen, den Anforderungshauptteil in der vom URI angegebenen Ressource zu speichern, oder es kann sich um einen anderen URI oder um eine andere Aktion handeln.

PUT ist wie ein Datei-Upload. Ein Put auf einen URI wirkt sich genau auf diesen URI aus. Ein POST an eine URI kann überhaupt Auswirkungen haben.

So geben Sie Beispiele für Ressourcen im REST-Stil:

"POST / books" mit einer Reihe von Buchinformationen erstellt möglicherweise ein neues Buch und antwortet mit der neuen URL, die das Buch identifiziert: "/ books / 5".

"PUT / books / 5" müsste entweder ein neues Buch mit der ID 5 erstellen oder das vorhandene Buch durch die ID 5 ersetzen.

Im Nicht-Ressourcen-Stil kann POST für nahezu alles verwendet werden, was Nebenwirkungen hat. Ein weiterer Unterschied besteht darin, dass PUT idempotent sein sollte - mehrere PUTs derselben Daten zu derselben URL sollten in Ordnung sein, wobei mehrere POSTs möglicherweise mehrere Objekte erstellen oder was auch immer Ihre POST-Aktion tut.

1. GET : Ruft Daten vom Server ab. Sollte keine andere Wirkung haben.
2. POST : Sendet Daten an den Server, um eine neue Entität zu erstellen. Wird häufig beim Hochladen einer Datei oder beim Senden eines Webformulars verwendet.
3. PUT : Ähnlich wie POST, wird jedoch verwendet, um eine vorhandene Entität zu ersetzen.
4. PATCH : Ähnlich wie PUT, wird jedoch verwendet, um nur bestimmte Felder innerhalb einer vorhandenen Entität zu aktualisieren.
5. LÖSCHEN : Entfernt Daten vom Server.
6. TRACE : Bietet eine Möglichkeit zu testen, was der Server empfängt. Es wird einfach zurückgegeben, was gesendet wurde.
7. OPTIONEN : Ermöglicht einem Client, Informationen zu den von einem Dienst unterstützten Anforderungsmethoden abzurufen . Der relevante Antwortheader lautet Zulassen mit unterstützten Methoden. Wird auch in CORS als Preflight-Anforderung verwendet, um den Server über die tatsächliche Anforderungsmethode zu informieren und nach benutzerdefinierten Headern zu fragen.
8. HEAD : Gibt nur die Antwortheader zurück.
9. CONNECT : Wird vom Browser verwendet, wenn er weiß, dass er mit einem Proxy kommuniziert und der endgültige URI mit https: // beginnt. Die Absicht von CONNECT ist es, eine durchgängig verschlüsselte TLS-Sitzung zuzulassen, sodass die Daten für einen Proxy nicht lesbar sind.

PUT ist als Methode zum "Hochladen" von Inhalten in eine bestimmte URI oder zum Überschreiben der bereits in dieser URI enthaltenen Elemente gedacht.

POST hingegen ist eine Möglichkeit, Daten in Bezug auf einen bestimmten URI zu senden.

Siehe HTTP-RFC

Soweit ich weiß, wird PUT hauptsächlich zum Aktualisieren der Datensätze verwendet.

1. POST - Zum Erstellen eines Dokuments oder einer anderen Ressource

2. PUT - Zum Aktualisieren des erstellten Dokuments oder einer anderen Ressource.

Um jedoch klar zu sein, ersetzt PUT normalerweise den vorhandenen Datensatz, wenn er vorhanden ist, und erstellt ihn, wenn er nicht vorhanden ist.

Andere haben bereits hervorragende Antworten veröffentlicht. Ich wollte nur hinzufügen, dass Sie mit den meisten Sprachen, Frameworks und Anwendungsfällen viel, viel häufiger mit POST als mit PUT zu tun haben. Bis zu dem Punkt, an dem PUT, DELETE usw. im Grunde Trivia-Fragen sind.

Bitte sehen Sie: http://zacharyvoase.com/2009/07/03/http-post-put-diff/

Ich habe mich in letzter Zeit ziemlich über ein weit verbreitetes Missverständnis von Webentwicklern geärgert, dass ein POST zum Erstellen einer Ressource und ein PUT zum Aktualisieren / Ändern einer Ressource verwendet wird.

Wenn Sie sich Seite 55 von RFC 2616 („Hypertext Transfer Protocol - HTTP / 1.1“), Abschnitt 9.6 („PUT“) ansehen, werden Sie sehen, wofür PUT eigentlich gedacht ist:

Die PUT-Methode fordert an, dass die eingeschlossene Entität unter dem angegebenen Anforderungs-URI gespeichert wird.

Es gibt auch einen praktischen Absatz, um den Unterschied zwischen POST und PUT zu erklären:

Der grundlegende Unterschied zwischen den POST- und PUT-Anforderungen spiegelt sich in der unterschiedlichen Bedeutung des Anforderungs-URI wider. Der URI in einer POST-Anforderung gibt die Ressource an, die die eingeschlossene Entität verarbeitet. Diese Ressource kann ein Datenakzeptanzprozess, ein Gateway zu einem anderen Protokoll oder eine separate Entität sein, die Anmerkungen akzeptiert. Im Gegensatz dazu identifiziert der URI in einer PUT-Anforderung die Entität, die der Anforderung beigefügt ist. Der Benutzeragent weiß, welcher URI beabsichtigt ist, und der Server darf NICHT versuchen, die Anforderung auf eine andere Ressource anzuwenden.

Es wird nichts über den Unterschied zwischen Aktualisieren / Erstellen erwähnt, da es nicht darum geht. Es geht um den Unterschied zwischen diesen:

obj.set_attribute(value) # A POST request.

Und das:

obj.attribute = value # A PUT request.

Stoppen Sie also bitte die Verbreitung dieses populären Missverständnisses. Lesen Sie Ihre RFCs.

Ein POST wird als eine Art Factory-Methode betrachtet. Sie fügen Daten hinzu, um zu erstellen, was Sie möchten, und was sich am anderen Ende befindet, weiß, was damit zu tun ist. Ein PUT wird verwendet, um vorhandene Daten unter einer bestimmten URL zu aktualisieren oder um etwas Neues zu erstellen, wenn Sie wissen, wie der URI aussehen wird und er noch nicht vorhanden ist (im Gegensatz zu einem POST, der etwas erstellt und eine URL an zurückgibt es wenn nötig).

REST fordert Entwickler auf, HTTP-Methoden explizit und in einer Weise zu verwenden, die mit der Protokolldefinition übereinstimmt. Dieses grundlegende REST-Entwurfsprinzip erstellt eine Eins-zu-Eins-Zuordnung zwischen CRUD-Operationen (Erstellen, Lesen, Aktualisieren und Löschen) und HTTP-Methoden. Nach dieser Zuordnung:

• Verwenden Sie POST, um eine Ressource auf dem Server zu erstellen.

• Verwenden Sie GET, um eine Ressource abzurufen.

• Verwenden Sie PUT, um den Status einer Ressource zu ändern oder zu aktualisieren.

• Um eine Ressource zu entfernen oder zu löschen, verwenden Sie LÖSCHEN.

Weitere Informationen: RESTful Web Services: Die Grundlagen von IBM

Es sollte ziemlich einfach sein, wann man das eine oder das andere verwendet, aber komplexe Formulierungen sorgen für viele von uns für Verwirrung.

Wann man sie benutzt:

• Verwenden PUTSie diese Option, wenn Sie eine einzelne Ressource ändern möchten, die bereits Teil der Ressourcensammlung ist. PUTersetzt die Ressource in ihrer Gesamtheit. Beispiel:PUT /resources/:resourceId

  Nebenbemerkung: Verwenden PATCHSie diese Option, wenn Sie einen Teil der Ressource aktualisieren möchten.

• Verwenden POSTSie diese Option, wenn Sie eine untergeordnete Ressource zu einer Sammlung von Ressourcen hinzufügen möchten.
  Beispiel:POST => /resources

Allgemein:

• Im Allgemeinen wird in der Praxis verwendet immer PUTfür UPDATE - Operationen.
• Immer POSTfür CREATE- Operationen verwenden.

Beispiel:

GET / company / reports => Alle Berichte abrufen
GET / company / reports / {id} => Abrufen der durch "id" gekennzeichneten Berichtsinformationen
POST / company / reports => Neuen Bericht erstellen
PUT / company / reports / {id} => Aktualisieren Sie die Berichtsinformationen, die durch "ID"
PATCH / Firma / Berichte / {ID} => gekennzeichnet sind Aktualisieren Sie einen Teil der Berichtsinformationen, die durch "ID"
DELETE / Firma / Berichte / {ID} => gekennzeichnet sind. Löschen Sie den Bericht durch "ID".

Der Unterschied zwischen POST und PUT besteht darin, dass PUT idempotent ist. Das bedeutet, dass das mehrfache Aufrufen derselben PUT-Anforderung immer das gleiche Ergebnis liefert (dies ist kein Nebeneffekt), während das wiederholte Aufrufen einer POST-Anforderung möglicherweise ( zusätzliche) Nebenwirkungen beim mehrmaligen Erstellen derselben Ressource.

GET : Anforderungen, die GET verwenden, rufen nur Daten ab, dh sie fordern eine Darstellung der angegebenen Ressource an

POST: Es sendet Daten an den Server, um eine Ressource zu erstellen. Der Typ des Hauptteils der Anforderung wird durch den Content-Type-Header angegeben. Dies führt häufig zu einer Änderung des Status oder zu Nebenwirkungen auf dem Server

PUT : Erstellt eine neue Ressource oder ersetzt eine Darstellung der Zielressource durch die Anforderungsnutzlast

PATCH : Es wird verwendet, um teilweise Änderungen an einer Ressource vorzunehmen

DELETE : Löscht die angegebene Ressource

TRACE : Es führt einen Nachrichten-Loopback-Test entlang des Pfads zur Zielressource durch und bietet einen nützlichen Debugging-Mechanismus

OPTIONS : Es wird verwendet, um die Kommunikationsoptionen für die Zielressource zu beschreiben. Der Client kann eine URL für die OPTIONS-Methode oder ein Sternchen (*) angeben, das auf den gesamten Server verweist.

HEAD : Es wird nach einer Antwort gefragt, die mit der einer GET-Anforderung identisch ist, jedoch ohne den Antworttext

CONNECT : Es wird ein Tunnel zum Server eingerichtet, der von der Zielressource identifiziert wird. Es kann verwendet werden, um auf Websites zuzugreifen, die SSL (HTTPS) verwenden.

REST-volle Nutzung

POST wird verwendet, um eine neue Ressource zu erstellen und die Ressource dann zurückzugeben URI

EX 
      REQUEST : POST ..../books
        {
        "book":"booName",
        "author":"authorName"
        }

Dieser Aufruf erstellt möglicherweise ein neues Buch und gibt dieses Buch zurück URI

Response ...THE-NEW-RESOURCE-URI/books/5

PUT wird verwendet, um eine Ressource zu ersetzen. Wenn diese Ressource vorhanden ist, aktualisieren Sie sie einfach. Wenn diese Ressource jedoch nicht vorhanden ist, erstellen Sie sie.

REQUEST : PUT ..../books/5
{
"book":"booName",
"author":"authorName"
}

Mit PUTkennen wir die Ressourcen-ID, geben aber POSTdie neue Ressourcen-ID zurück

Nicht REST-volle Nutzung

POST wird verwendet, um eine Aktion auf der Serverseite zu initiieren. Diese Aktion kann eine Ressource erstellen oder nicht, aber diese Aktion hat Nebenwirkungen, die immer etwas auf dem Server ändern

PUT wird verwendet, um Literalinhalte unter einer bestimmten URL zu platzieren oder zu ersetzen

Ein weiterer Unterschied zwischen REST-Ful- und Nicht-REST-Ful-Stilen

POST is Non-Idempotent Operation: Bei mehrmaliger Ausführung mit derselben Anforderung werden einige Änderungen vorgenommen.

PUT is Idempotent Operation: Es hat keine Nebenwirkungen, wenn es mehrmals mit derselben Anfrage ausgeführt wird.

Es ist erwähnenswert, dass dies POSTeinigen häufigen CSRF-Angriffen (Cross-Site Request Forgery) unterliegt, obwohl dies PUTnicht der Fall ist.

Die unten aufgeführten CSRF sind bei Besuchen des Opfers nicht möglichPUTattackersite.com .

Die Wirkung des Angriffs ist , dass das Opfer unbeabsichtigt einen Benutzer löscht , nur weil es (das Opfer) wurde angemeldet in als adminauf target.site.com, vor dem Besuch attackersite.com:

Normale Anfrage (Cookies werden gesendet): ( PUTist kein unterstützter Attributwert)

Code auf attackersite.com:

<form id="myform" method="post" action="http://target.site.com/deleteUser" >
    <input type="hidden" name="userId" value="5">
</form>
<script>document.createElement('form').submit.call(document.getElementById('myform'));</script>

XHR-Anfrage (Cookies werden gesendet): ( PUTwürde eine Preflight-Anfrage auslösen, deren Antwort den Browser daran hindern würde, die deleteUserSeite anzufordern )

var xhr = new XMLHttpRequest();
xhr.open("POST", "http://target.site.com/deleteUser");
xhr.withCredentials=true;
xhr.send(["userId=5"]);

In einfachen Worten kann man sagen:

1.HTTP Get: Es wird verwendet, um ein oder mehrere Elemente abzurufen

2.HTTP-Post: Wird zum Erstellen eines Elements verwendet

3.HTTP Put: Dient zum Aktualisieren eines Elements

4.HTTP-Patch: Wird verwendet, um ein Element teilweise zu aktualisieren

5.HTTP Löschen: Dient zum Löschen eines Elements

Eigentlich gibt es keinen anderen Unterschied als ihren Titel. Es gibt tatsächlich einen grundlegenden Unterschied zwischen GET und den anderen. Mit einer "GET" -Request-Methode senden Sie die Daten in der URL-Adresszeile, die zuerst durch ein Fragezeichen und dann durch ein & -Zeichen getrennt sind.

Bei einer "POST" -Anforderungsmethode können Sie jedoch keine Daten über die URL übergeben, sondern müssen die Daten als Objekt im sogenannten "Body" der Anforderung übergeben. Auf der Serverseite müssen Sie dann den Hauptteil des empfangenen Inhalts auslesen, um die gesendeten Daten zu erhalten. Auf der anderen Seite gibt es jedoch keine Möglichkeit, Inhalte im Textkörper zu senden, wenn Sie eine "GET" -Request senden.

Die Behauptung, dass "GET" nur zum Abrufen von Daten und "POST" zum Posten von Daten dient, ist absolut falsch. Niemand kann Sie daran hindern, neuen Inhalt zu erstellen, vorhandenen Inhalt zu löschen, vorhandenen Inhalt zu bearbeiten oder irgendetwas im Backend zu tun, basierend auf den Daten, die von der "GET" -Anforderung oder von der "POST" -Anforderung gesendet werden. Und niemand kann Sie daran hindern, das Backend so zu codieren, dass der Client bei einer "POST" -Request nach einigen Daten fragt.

Unabhängig von der verwendeten Methode rufen Sie bei einer Anfrage eine URL auf und senden oder senden keine Daten, um anzugeben, welche Informationen Sie zur Bearbeitung Ihrer Anfrage an den Server übergeben möchten. Anschließend erhält der Client eine Antwort von der Kellner. Die Daten können alles enthalten, was Sie senden möchten, das Backend kann mit den Daten tun, was es will, und die Antwort kann alle Informationen enthalten, die Sie dort eingeben möchten.

Es gibt nur diese beiden GRUNDMETHODEN. GET und POST. Aber es ist ihre Struktur, die sie anders macht und nicht das, was Sie im Backend codieren. Im Backend können Sie mit den empfangenen Daten beliebig codieren. Aber mit der "POST" -Anforderung müssen Sie die Daten im Body und nicht in der URL-Adresszeile senden / abrufen, und mit einer "GET" -Anforderung müssen Sie Daten in der URL-Adresszeile senden und abrufen und nicht in der Körper. Das ist alles.

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

Die POST-Methode wird hauptsächlich verwendet, wenn Sie den Inhalt etwas verbergen möchten, da alles, was Sie in die URL-Adresszeile schreiben, im Cache gespeichert wird und eine GET-Methode dem Schreiben einer URL-Adresszeile mit Daten entspricht. Wenn Sie also vertrauliche Daten senden möchten, bei denen es sich nicht immer um Benutzername und Kennwort handelt, sondern beispielsweise um einige IDs oder Hashes, die nicht in der URL-Adresszeile angezeigt werden sollen, sollten Sie die POST-Methode verwenden .

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

Die Bearbeitung der GET-Anfrage ist jedoch viel einfacher, wenn Sie keinen komplizierten Text senden müssen. Andernfalls, und dies ist ein weiterer Pluspunkt für die POST-Methode, müssen Sie bei der GET-Methode den Text per URL codieren, um einige Symbole innerhalb des Textes oder sogar Leerzeichen senden zu können. Mit einer POST-Methode haben Sie jedoch keine Einschränkungen und Ihr Inhalt muss in keiner Weise geändert oder manipuliert werden.

Sowohl PUT als auch POST sind Restmethoden.

PUT - Wenn wir dieselbe Anforderung zweimal mit PUT unter Verwendung derselben Parameter beide Male stellen, hat die zweite Anforderung keine Auswirkung. Aus diesem Grund wird PUT im Allgemeinen für das Update-Szenario verwendet. Wenn Sie Update mehrmals mit denselben Parametern aufrufen, wird nur der erste Aufruf ausgeführt, sodass PUT idempotent ist.

POST ist nicht idempotent, zum Beispiel erstellt Create zwei separate Einträge im Ziel, daher ist es nicht idempotent, so dass CREATE in POST weit verbreitet ist.

Wenn Sie jedes Mal denselben Anruf mit POST mit denselben Parametern tätigen, passieren zwei verschiedene Dinge. Daher wird POST häufig für das Szenario "Erstellen" verwendet