it-swarm.com.de

Was ist der Unterschied zwischen a POST und eine PUT-HTTP-ANFRAGE?

Sie scheinen beide Daten an den Server innerhalb des Körpers zu senden. Was unterscheidet sie also?

673
fuentesjr

HTTP PUT:

PUT stellt eine Datei oder Ressource an einen bestimmten URI und genau an diesen URI. Wenn sich unter diesem URI bereits eine Datei oder Ressource befindet, ersetzt PUT diese Datei oder Ressource. Wenn sich dort keine Datei oder Ressource befindet, erstellt PUT eine. PUT ist idempotent , aber paradoxerweise sind PUT-Antworten nicht zwischengespeichert.

HTTP 1.1-RFC-Speicherort für PUT

HTTP POST: 

Der POST sendet Daten an einen bestimmten URI und erwartet, dass die Ressource an diesem URI die Anforderung verarbeitet. Der Webserver kann an dieser Stelle festlegen, was mit den Daten im Kontext der angegebenen Ressource zu tun ist. Die Methode POST ist nicht idempotent , die Antworten von POST sind jedoch zwischengespeichert, solange der Server die entsprechenden Header für Cache-Control und Expires setzt.

Der offizielle HTTP-RFC gibt POST an:

  • Anmerkung zu vorhandenen Ressourcen;
  • Senden einer Nachricht an ein Bulletin Board, eine Newsgroup, eine Mailingliste, oder eine ähnliche Gruppe von Artikeln;
  • Bereitstellung eines Datenblocks, z. B. das Ergebnis der Übermittlung einer Formular, zu einem Datenverarbeitungsprozess;
  • Erweitern einer Datenbank durch einen Anfügevorgang 

HTTP 1.1-RFC-Speicherort für POST

Unterschied zwischen POST und PUT:

Der RFC selbst erklärt den Hauptunterschied:

Der grundlegende Unterschied zwischen der POST und PUT-Anforderungen werden in .__ wiedergegeben. die unterschiedliche Bedeutung des Anforderungs-URI. Die URI in einer POST - Anforderung gibt die Ressource an, die handhabt die eingeschlossene Entität. Das Die Ressource ist möglicherweise eine Datenannahme Prozess, ein Gateway zu einem anderen Protokoll oder eine separate Entität, die nimmt Anmerkungen an. Im Gegensatz dazu ist die Die URI in einer PUT-Anforderung identifiziert die Entität, die der Anforderung beiliegt -- Der Benutzeragent weiß, was URI ist beabsichtigt und der Server darf nicht Versuchen Sie, die Anforderung auf einige .__ anzuwenden. andere Ressource. Wenn der Server wünscht dass die Anforderung auf eine .__ angewendet wird. andere URI, MUSS eine 301-Antwort (Moved Permanently) gesendet werden; der Benutzeragent kann dann seine eigene Entscheidung darüber, ob die Anfrage umgeleitet werden soll oder nicht.

Mit der richtigen Methode, beiseite nicht verwandt:

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

693
Brian R. Bondy

Nur Semantik.

Ein HTTP-PUT soll den Hauptteil der Anforderung akzeptieren und dann in der durch den URI angegebenen Ressource speichern.

Ein HTTP-POST ist allgemeiner. Es soll eine Aktion auf dem Server auslösen. Diese Aktion könnte darin bestehen, den Anfragetext bei der durch den URI angegebenen Ressource zu speichern, oder es könnte sich um einen anderen URI handeln oder es könnte sich um eine andere Aktion handeln.

PUT ist wie ein Dateiupload. Ein Put zu einem URI wirkt sich genau auf diesen URI aus. Ein POST für einen URI kann überhaupt Auswirkungen haben.

170
Jonathan Arkell

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

"POST/books" mit einer Reihe von Buchinformationen kann ein neues Buch erstellen und mit der neuen URL antworten, die dieses 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 fast alles verwendet werden, was Nebeneffekte hat. Ein weiterer Unterschied ist, dass PUT idempotent sein sollte - mehrere PUTs derselben Daten unter derselben URL sollten in Ordnung sein, wobei mehrere POSTs möglicherweise mehrere Objekte erstellen oder was auch immer Ihre Aktion POST ist.

103
bhollis

PUT ist als Methode zum "Hochladen" von Daten in einen bestimmten URI oder zum Überschreiben dessen, was bereits in diesem URI enthalten ist, gedacht.

Auf der anderen Seite ist POST ein Weg, um Daten an einen bestimmten URI zu übermitteln.

Siehe den HTTP-RFC

55
Daniel Bruce

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 - Um das erstellte Dokument oder eine andere Ressource zu aktualisieren.

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

38
ChanGan

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

16
Jason Morrison
  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 beim POST, wird jedoch verwendet, um eine vorhandene Entität zu ersetzen.
  4. PATCH: Ähnlich wie PUT, wird aber nur zum Aktualisieren bestimmter Felder in einer vorhandenen Entität verwendet.
  5. DELETE: Entfernt Daten vom Server.
  6. TRACE: Ermöglicht das Testen, was der Server empfängt. Es wird einfach zurückgeschickt, was gesendet wurde.
  7. OPTIONS: Ermöglicht einem Client das Abrufen von Informationen zu den Anforderungsmethoden, die von einem Dienst unterstützt werden. Der entsprechende Antwortheader ist 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 Kopfzeilen zu fragen.
  8. HEAD: Gibt nur die Antwortheader zurück.
  9. CONNECT: Wird vom Browser verwendet, wenn er weiß, dass er mit einem Proxy spricht und der endgültige URI mit https: // beginnt. Die Absicht von CONNECT ist es, Ende-zu-Ende-verschlüsselte TLS-Sitzungen zuzulassen, sodass die Daten für einen Proxy nicht lesbar sind. 
13
walkerbox

Ein POST wird als eine Art Fabrikmethode betrachtet. Sie fügen Daten hinzu, um das zu erstellen, was Sie möchten, und was auch immer am anderen Ende ist, weiß, was damit zu tun ist. Ein PUT wird verwendet, um vorhandene Daten unter einer bestimmten URL zu aktualisieren oder etwas Neues zu erstellen, wenn Sie wissen, was der URI sein wird, und es ist noch nicht vorhanden (im Gegensatz zu einem POST), der etwas erstellt ggf. eine URL zurücksenden). 

11
user12786

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

Ich wurde in letzter Zeit ziemlich ärgerlich durch ein weit verbreitetes Missverständnis von Webentwicklern, dass ein POST zum Erstellen einer Ressource verwendet wird und ein PUT zum Aktualisieren/Ändern einer Ressource.

Wenn Sie einen Blick auf Seite 55 von RFC 2616 („Hypertext Transfer Protocol - HTTP/1.1“) und Abschnitt 9.6 („PUT“) werfen, sehen Sie, was PUT eigentlich ist:

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

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

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

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

obj.set_attribute(value) # A POST request.

Und das:

obj.attribute = value # A PUT request.

Also, bitte, stoppen Sie die Verbreitung dieses populären Missverständnisses. Lesen Sie Ihre RFCs.

9
Najeebul Hasan

REST fordert Entwickler auf, HTTP-Methoden explizit und in einer Weise zu verwenden, die mit der Protokolldefinition Konsistent ist. Dieses grundlegende REST - Entwurfsprinzip führt zu einer Eins-zu-Eins-Zuordnung zwischen CRUD-Vorgängen (CRUD) und HTTP-Methoden. Nach diesem Mapping:

• Zum Erstellen einer Ressource auf dem Server verwenden Sie POST.

• Um eine Ressource abzurufen, verwenden Sie GET.

• Um den Status einer Ressource zu ändern oder zu aktualisieren, verwenden Sie PUT.

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

Weitere Informationen: RESTful Web Services: Die Grundlagen von IBM

9
Long Nguyen

Erwähnenswert ist, dass POST einigen häufigen CSRF-Angriffen ausgesetzt ist während PUT keiner ist.

Die CSRF unten sind mit PUT nicht möglich wenn das Opfer attackersite.com besucht:

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

<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): (PUT würde eine Preflight-Anfrage auslösen)

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

Einfach

POST wird zum Erstellen einer Ressource verwendet und gibt die Ressource URI EX zurück

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

Dieser Aufruf sollte ein neues Buch erstellen und dieses Buch zurückgeben URI

Response ..../books/5

PUT wird zum Ersetzen einer Ressource verwendet. 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 PUT geben wir die Ressourcenkennung an, mit POST wird die neue Ressourcenkennung zurückgegeben

0
Melad Ezzat

Der Unterschied zwischen POST und PUT besteht darin, dass PUT idempotent ist. Das bedeutet, dass ein mehrfacher Aufruf derselben PUT-Anforderung immer dasselbe Ergebnis (d. H. Keine Nebenwirkung) ergibt, während andererseits ein Aufruf von POST kann wiederholt (zusätzliche) Nebenwirkungen haben, wenn dieselbe Ressource mehrmals erstellt wird.

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 verursacht häufig eine Änderung des Status oder der Nebenwirkungen auf dem Server

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

PATCH: Wird verwendet, um Teiländerungen an einer Ressource vorzunehmen

DELETE: Löscht die angegebene Ressource

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

OPTIONS: Wird verwendet, um die Kommunikationsoptionen für die Zielressource zu beschreiben. Der Client kann eine URL für die Methode OPTIONS angeben oder einen Stern (*), der sich auf den gesamten Server bezieht.

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

CONNECT: Errichtet einen Tunnel zum Server, der von der Zielressource identifiziert wird. Er kann für den Zugriff auf Websites verwendet werden, die SSL (HTTPS) verwenden.

0
qaautodev