SETZEN vs. POST in RUHE

Gemäß dem HTTP/1.1 Spec:

Den POST - Methode wird verwendet, um anzufordern, dass der Ursprungs-server akzeptieren Sie die Einheit eingeschlossen in der Anforderung als eine neue untergeordnete der Ressource identifiziert, die durch die Request-URI im Request-Line

In anderen Worten, POST wird verwendet, um erstellen.

Den PUT Methode fordert an, dass die eingeschlossene Person gespeichert werden, die unter der mitgelieferten Request-URI. Wenn die Request-URI bezieht sich auf eine bereits vorhandene Ressource, die geschlossene Einheit betrachtet werden SOLLTE, als eine modifizierte version des einen, der sich auf dem Ursprungs-server. Wenn die Request-URI nicht auf eine vorhandene Ressource, und dieser URI ist in der Lage, die definiert wird als eine neue Ressource, die von der anfragenden user agent, der origin server kann die Ressource mit URI."

Dass PUT wird verwendet, um erstellen oder aktualisieren.

So, welche soll verwendet werden, um eine Ressource zu erstellen? Oder braucht man Unterstützung?

Es kann hilfreich sein, die Definitionen in der HTTPbis - Roy legte eine Menge Arbeit in die Klärung von Ihnen. Siehe: tools.ietf.org/html/...
Nur bringen @MarkNottingham Kommentar auf die aktuelle Version, hier ist BEITRAG und PUT, wie definiert auf HTTPbis.
Es scheint mir, daß diese Debatte ist entstanden aus der gemeinsamen Praxis zu kurz gedacht REST durch die Beschreibung der HTTP-Methoden in Bezug auf die CRUD-Operationen.
Unglücklicher Weise sind die ersten Antworten sind falsch über POST. Check meine Antwort zur besseren Erklärung der Unterschiede: stackoverflow.com/a/18243587/2458234
PUT und POST sind beide unsichere Methoden. Aber, SETZEN Sie ist idempotent, während die POST nicht. - Sehen Sie mehr unter: restcookbook.com/HTTP%20Methods/put-vs-post/...

InformationsquelleAutor alex | 2009-03-10

3905

Insgesamt:

PUT und POST können verwendet werden, für die Erstellung.

Haben Sie zu Fragen, "was machen Sie mit der Durchführung der Aktion?", zu unterscheiden, was Sie verwenden sollten. Nehmen wir an, Sie entwerfen eine API, Fragen zu stellen. Wenn Sie möchten, verwenden Sie den POST dann würden Sie tun, um zu einer Liste von Fragen. Wenn Sie verwenden möchten LEGEN Sie dann Sie würde tun, um zu einer bestimmten Frage.

Großen beide können verwendet werden, also was sollte ich verwenden in meinem RESTful design:

Brauchen Sie nicht zu unterstützen, PUT und POST.

Welches verwendet wird. Aber denken Sie nur daran, die richtige-je nachdem, was Objekt, das Sie referenzieren in der Anfrage.

Einige überlegungen:
- Tun, Sie geben Ihre URL-Objekte, die Sie erstellen, explizit, oder Sie lassen den server entscheiden? Wenn Sie Namen nennen, dann verwenden SETZEN. Wenn du den server entscheiden, dann verwenden Sie den POST.
- PUT idempotent, so, wenn Sie ein Objekt zweimal, es hat keine Wirkung. Dies ist ein schönes Anwesen, so würde ich SETZEN, wenn möglich.
- Können Sie aktualisieren oder erstellen Sie eine Ressource mit PUT mit dem gleichen Objekt-URL
- Mit POST können Sie haben 2 Anfragen zur gleichen Zeit, so dass änderungen an einer URL, und Sie können aktualisieren Sie die verschiedenen Teile des Objekts.
Ein Beispiel:

Ich schrieb das folgende als Teil einer anderen Antwort auf SO zu das:
POST:

Verwendet, zu modifizieren und aktualisieren einer Ressource
```
POST /questions/<existing_question> HTTP/1.1
Host: www.example.com/
```
Beachten Sie, dass der folgende Code ist ein Fehler:
```
POST /questions/<new_question> HTTP/1.1
Host: www.example.com/
```
Wenn die URL noch nicht erstellt, Sie
sollte nicht mit der POST, um es zu schaffen
während Sie den Namen angeben. Dies sollte
Ergebnis in einem "Ressource nicht gefunden" - Fehler
da <new_question> existiert nicht
noch. Sollten Sie die <new_question>
Ressource auf dem server.

Könnte man zwar so etwas machen
das erstellen von Ressourcen mithilfe von POST:
```
POST /questions HTTP/1.1
Host: www.example.com/
```
Beachten Sie, dass in diesem Fall die Ressource
name nicht angegeben wird, werden die neuen Objekte
URL-Pfad würde Ihnen zurückgegeben werden.

SETZEN:

Verwendet, um eine Ressource zu erstellen, oder
überschreiben Sie ihn. Beim angeben des
Ressourcen für die neue URL.

Für eine neue Ressource:
```
PUT /questions/<new_question> HTTP/1.1
Host: www.example.com/
```
Überschreiben einer vorhandenen Ressource:
```
PUT /questions/<existing_question> HTTP/1.1
Host: www.example.com/
```
Ich denke, man kann nicht genug betonen, die Tatsache, dass PUT idempotent: wenn das Netzwerk ist Murks und der Kunde nicht sicher ist, ob sein Antrag durch, es kann schicken Sie es einfach ein zweites (oder 100) mal, und es wird garantiert, indem der HTTP-Spezifikation, die dieser hat genau die gleiche Wirkung wie das senden einmal.
W Mittag: Nicht erforderlich. Das zweite mal zurückgeben könnte, 409 Konflikt oder etwas, wenn der Antrag geändert wurde in der Zwischenzeit durch andere Benutzer oder die erste Anfrage selbst, welches schon durch).
Wenn ich mich nicht Irre, was wir sein sollten betont wird, ist definiert idempotent. Sie haben noch zu schreiben, Ihre server in einer Weise, verhält sich korrekt, ja? Vielleicht ist es besser, zu sagen "SETZEN bewirkt, dass der transport zu übernehmen, idempotenz, die möglicherweise auf das Verhalten des transport -, z.B. caching".
Idempotenz Schlagwort? Wie wärs mit "Senden und senden und senden, mein Freund, es macht keinen Unterschied am Ende."
Sie denkt, wie: PUT = insert-oder update; POST = einfügen. Also, wenn Sie zwei STELLEN - Sie erhalten eine neue Platte, wenn du zwei Beiträge - erhalten Sie zwei neue Datensätze.

InformationsquelleAutor Brian R. Bondy
2061

Finden Sie Behauptungen im web, die sagen,
- "POST sollte verwendet werden, um eine Ressource zu erstellen, und PUT sollte verwendet werden, zu ändern
- PUT sollte verwendet werden, um eine Ressource zu erstellen, und POST sollte verwendet werden, zu ändern
Weder ganz richtig ist.

Besser ist, zu wählen zwischen PUT und POST basiert auf idempotenz der Aktion.

SETZEN impliziert setzen eine Ressource - vollständig zu ersetzen, was zur Verfügung steht an die angegebene URL mit einer anderen Sache. Per definition, eine PUT idempotent. Tun Sie es so viele Male, wie Sie möchten, und das Ergebnis ist das gleiche. x=5 ist idempotent. Sie können eine Ressource, ob es vorher existiert, oder nicht (zB, zu Erstellen oder zu Aktualisieren)!

POST aktualisiert eine Ressource, fügt eine Tochtergesellschaft Ressource, oder bewirkt eine Veränderung. Ein POST ist nicht idempotent, in der Weise, dass x++ ist nicht idempotent.

Durch dieses argument, PUT für das erstellen von wenn Sie wissen, dass die URL von dem, was Sie erstellen werden. POST kann verwendet werden, zu erstellen, wenn Sie wissen, die URL der "Fabrik" oder manager, die für die Kategorie der Dinge, die Sie erstellen möchten.

also:
```
POST /expense-report
```
oder:
```
PUT  /expense-report/10929
```
Ich bin damit einverstanden, wo idempotenz ist besorgt, sollte es trump sonstige Anliegen da zu bekommen, die falsche kann die Ursache für viele unerwartete Fehler.
Wenn POST aktualisieren können, eine Ressource, wie das ist, nicht idempotent? Wenn ich eine Schüler-Alter, unter Einsatz von PUT-und das 10x mal die Schüler-Alter ist die gleiche, wenn ich es einmal Tat.
in diesem Fall ist Ihr server macht einen zusätzlichen Aufwand zu garantieren idempotenz, aber es ist nicht Werbung. Browser wird immer noch warnen die Benutzer, wenn Sie versuchen, zu laden wie eine POST-Anfrage.
POST kann eine Tochtergesellschaft Ressource; daher können Sie POST-Erhebung, wie bei POST - /Kosten-Berichte und es schaffen würde, so viele Entitäten (Aufwand berichten) auf Ihren server als die Menge der Anfragen, die Sie gesendet haben, auch wenn Sie ganz ähnlich. Denken Sie an es als das einfügen der gleichen Zeile in der DB-Tabelle (/Kosten-Berichte) mit auto-increment primary key. Die Daten bleiben die gleichen, Schlüssel-URI (in diesem Fall) erzeugt wird, die von server und unterschiedlich für jedes andere insert (Anfrage). So, POST-Effekt kann werden idempotent, aber auch kann nicht. Also, POST ist nicht idempotent.
Lassen Sie uns sagen, wir haben Unternehmen, die möglicherweise zwei Eigenschaften - name und date. Wenn wir ein Unternehmen mit einem bestehenden name und date, aber dann Anfragen stellen, um es der Angabe von nur einem name, das richtige Verhalten von STELLEN würde zur Auslöschung der date des Unternehmens, wobei es sich bei POST Mai-update werden nur die Eigenschaften angegeben, verlassen die nicht spezifizierten Eigenschaften, wie Sie waren, bevor der Antrag gestellt wurde. Klingt das richtig/vernünftig, oder ist es eine unsachgemäße Verwendung der STELLEN (sah ich Verweise auf PATCH, die es scheint, wäre besser geeignet, aber noch nicht existiert)?

InformationsquelleAutor Cheeso
648
- POST zu einer URL erstellt eine Kind-Ressource bei einer - server definiert URL.
- SETZEN zu einer URL erstellt/ersetzt die Ressource in seiner Gesamtheit auf die client definiert URL.
- PATCH zu einer URL updates Teil der Ressource an, die vom client definierte URL.
Die relevante Spezifikation für PUT und POST ist RFC 2616 §9.5 ff.

POST erstellt eine Kind-Ressource, so ein POST zu /items schafft ein Mittel, das lebt unter der /items Ressource.
ZB. /items/1. Senden Sie den gleichen Beitrag Paket zweimal zwei Ressourcen.

SETZEN ist für das erstellen oder ersetzen Sie eine Ressource in einem URL vom AUFTRAGGEBER bekannt.

Daher: SETZEN ist nur ein Kandidat für das ERSTELLEN, wo der Kunde schon weiß, die url, bevor die Ressource erstellt wird. ZB. /blogs/nigel/entry/when_to_use_post_vs_put wie der Titel dient als resource key

SETZEN ersetzt die Ressource an der url bekannt, wenn es bereits vorhanden ist, so sendet die gleiche Anfrage zweimal keine Wirkung hat. In anderen Worten, Aufrufe von PUT idempotent sind.

RFC liest sich wie diese:

Den grundlegenden Unterschied zwischen POST und PUT Anfragen spiegelt sich in der unterschiedlichen Bedeutung der Anfrage-URI. Die URI in einer POST-Anforderung identifiziert die Ressource, die mit der eingeschlossenen Person. Diese Ressource könnte eine Daten-Annahme-Prozess, ein Tor zu einigen anderen Protokoll, oder eine separate Einheit, die akzeptiert Anmerkungen. Im Gegensatz dazu, der URI in eine PUT-Anforderung identifiziert die Entität, eingeschlossen mit den Wunsch-den user-agent weiß, was URI soll und der server MUSS NICHT versuchen auf anwenden, um die Anfrage zu einigen anderen Ressourcen. Wenn der server wünscht, dass die Anfrage angewendet werden, um einen anderen URI,

Hinweis: SETZEN sich hauptsächlich verwendet, um die update-Ressourcen (indem Sie Sie in Ihre entireties), aber in letzter Zeit gibt es Bewegung in Richtung PATCH für die Aktualisierung von vorhandenen Ressourcen, wie angegeben, dass es ersetzt die gesamte Ressource. RFC 5789.

Update 2018: Es ist ein Fall, gemacht werden können, zu vermeiden SETZEN. Sehen "RUHE, ohne VERSETZEN"

Mit "REST ohne PUT" - Technik, die Idee ist, dass Verbraucher
gezwungen, nach neuen 'nounified" Anforderungs-Ressourcen. Wie besprochen
früher, ändern Sie einen Kunden mailing-Adresse einen BEITRAG zu einer neuen
"ChangeOfAddress" Ressource, nicht von einem "Kunden" - Ressource mit einem
andere Adresse-Feld-Wert.

entnommen REST API Design - Ressource-Modellierung von Prakash Subramaniam von Thoughtworks

Diese Kräfte der API zu vermeiden, state-transition-Probleme mit mehreren clients die Aktualisierung einer einzelnen Ressource, und passt schön mit event-sourcing und CQRS. Wenn die Arbeit getan ist asynchron, Buchung der transformation und darauf warten, angewandt zu werden, scheint angemessen zu sein.

Oder von der anderen Seite des Zauns: SETZEN, wenn der client bestimmt die resultierende Ressource Adresse POSTEN, wenn der server das macht.
Ich denke, diese Antwort sollte sein editiert, um zu machen, mehr klar, was @DanMan wies in einer sehr einfachen Weise. Was ich finde, das wertvollste hier ist der Hinweis am Ende, die besagt, dass eine PUT-sollte nur verwendet werden, für den Austausch der gesamten Ressource.
PATCH ist nicht für eine realistische option für mindestens ein paar Jahre, aber ich Stimme mit der Ideologie.
Ich versuche zu verstehen, aber mit PUT etwas zu schaffen, das würde nur Sinn machen, wenn der Kunde weiß, für sicher, dass die Ressource noch nicht existiert, richtig? Nach dem blog-Beispiel, sagen Sie erstellt haben Hunderte von blog-posts in ein paar Jahren, dann versehentlich wählen Sie die Titel, wie Sie das für ein post vor zwei Jahren. Jetzt haben Sie verschwunden und ersetzt, die post, das war nicht beabsichtigt. Also mit PUT anlegen würde erfordern, dass die Kunden zu verfolgen, was genommen wird und was nicht, und könnte zu Unfällen und unbeabsichtigten Nebenwirkungen, sowie Routen, die zwei ganz unterschiedliche Dinge?
Sind Sie richtig. PUTting in einem blog-Beitrag mit der gleichen url wie eine vorhandene verursachen würde, ein update für diese vorhandene Stelle (obwohl Sie natürlich zunächst prüfen, mit einem GET). Dies zeigt, warum es wäre eine schlechte Idee, einfach den Titel als URL. Es würde jedoch die Arbeit überall dort, wo eine Natürliche Schlüssel in die Daten... was in meiner Erfahrung ist selten. Oder wenn Sie verwendet GUIDs

InformationsquelleAutor Nigel Thorne
190

Zusammenfassung:

Erstellen:

Durchgeführt werden können, mit PUT oder POST in der folgenden Weise:
SETZEN

Erstellt DIE neue Ressource mit newResourceId als identifier, unter dem /Ressourcen-URI, oder Sammlung.
```
PUT /resources/<newResourceId> HTTP/1.1 
```
POST

Erstellt Eine neue Ressource unter /Ressourcen-URI, oder Sammlung. In der Regel wird die id durch den server zurückgegeben.
```
POST /resources HTTP/1.1
```
Update:

Kann nur durchgeführt werden SETZEN Sie in der folgenden Weise:
SETZEN

Aktualisiert die Ressource mit existingResourceId als identifier, unter dem /Ressourcen-URI, oder Sammlung.
```
PUT /resources/<existingResourceId> HTTP/1.1
```
Erklärung:

Beim Umgang mit REST und URI als general, Sie haben generic auf die Links und bestimmten auf die Recht. Die Generika sind in der Regel als Sammlungen und mehr bestimmten Elemente aufgerufen werden können Ressource. Beachten Sie, dass eine Ressource enthalten kann Sammlung.
Beispiele:

<-- generisches -- bestimmte -->
```
URI: website.com/users/john
website.com  - whole site
users        - collection of users
john         - item of the collection, or a resource

URI:website.com/users/john/posts/23
website.com  - whole site
users        - collection of users
john         - item of the collection, or a resource
posts        - collection of posts from john
23           - post from john with identifier 23, also a resource
```
Wenn Sie POST Sie sind immer unter Bezugnahme auf einen Sammlung, so dass, wenn Sie sagen:
```
POST /users HTTP/1.1
```
Buchung einen neuen Benutzer zu Benutzer Sammlung.

Wenn Sie gehen und probieren Sie etwas wie dieses:
```
POST /users/john HTTP/1.1
```
wird es funktionieren, aber semantisch sagen Sie, dass Sie wollen, um eine Ressource hinzufügen, um die john Sammlung unter der Benutzer Sammlung.

Sobald Sie verwenden, SETZEN Sie sich auf eine Ressource oder einzelnes Element, möglicherweise innerhalb einer Sammlung. Also, wenn Sie sagen:
```
PUT /users/john HTTP/1.1
```
sagen Sie den server aktualisieren oder erstellen wenn es nicht vorhanden ist, die john Ressource unter der Benutzer Sammlung.

Spec:

Lassen Sie mich heben Sie einige wichtige Teile des spec:

POST

Den POST - Methode wird verwendet, um anzufordern, dass der Ursprungs-server akzeptieren die Einheit eingeschlossen in der Anfrage als neue untergeordnete der Ressource identifiziert durch die Request-URI im Request-Line

Also, erstellt eine neue Ressource auf eine Sammlung.

SETZEN

Den SETZEN Methode fordert, dass die geschlossenen Einheit werden gespeichert unter den gelieferten Anfrage-URI. Wenn die Request-URI bezieht sich auf ein bereits bestehenden Ressource, die geschlossene Einheit betrachtet werden SOLLTE, als modifizierte version der man sich auf der origin-server. Wenn der Request-URI nicht nicht auf eine bestehende Ressource, und dieser URI ist fähig definiert wird als neue Ressource durch den anfragenden user agent, der origin server kann erstellen die Ressource mit URI."

Daher erstellen oder zu aktualisieren, basierend auf der Existenz der Ressource.

Referenz:
Dieser post war hilfreich, um mich im Verständnis, dass die POST fügt hinzu, "etwas" wie ein Kind auf die angegebene collection (URI), in der Erwägung, dass STELLEN explizit definiert, die "etwas" unter der angegebenen URI-Speicherort.
Dies ist die beste Antwort hier, ich denke: keiner dieser "POST aktualisieren einer Ressource" Unsinn. Ich mag deine Aussage, "Update kann nur durchgeführt werden".
Nein, GESTELLT ist, nicht aktualisieren oder zu erstellen. Es ist für das ersetzen. Beachten Sie, dass Sie ersetzen kann, die nichts mit etwas für den Effekt zu erstellen.
PUT für die Aktualisierung mit einem kompletten Austausch, in anderen Worten, es ersetzt. Sie ersetzen nichts mit so etwas, oder etwas, mit einem völlig neuen etwas. PUT ist nicht für eine geringfügige änderung (es sei denn, Sie haben die Kunden, die kleine änderung und das gesamte neue version, auch was die übrigen das gleiche). Für die teilweise änderung, PATCH ist die Methode der Wahl.
Könnte man, aber wäre es nicht auch sein, klar, dass schaffen auch bedeckt es. In diesem Fall ist es besser eindeutig sein.

InformationsquelleAutor 7hi4g0
169

Ich möchte noch hinzufügen, dass meine "pragmatischen" Beratung. Verwenden Sie SETZEN, wenn Sie wissen, wo die "id", durch die das Objekt, das Sie speichern, können abgerufen werden. Mit PUT wird nicht allzu gut funktionieren, wenn Sie brauchen, sagen wir, einer Datenbank generierte id zurückgegeben werden für Sie tun, um künftige Suchvorgänge oder updates.

Also: wenn Sie einen vorhandenen Benutzer oder eine, wo der client generiert die id und es wurde verifiziert, dass die id eindeutig ist:
```
PUT /user/12345 HTTP/1.1  <-- create the user providing the id 12345
Host: mydomain.com

GET /user/12345 HTTP/1.1  <-- return that user
Host: mydomain.com
```
Andernfalls verwenden Sie POST, um zunächst das Objekt erstellen, und SETZEN, um das Objekt zu aktualisieren:
```
POST /user HTTP/1.1   <--- create the user, server returns 12345
Host: mydomain.com

PUT /user/12345 HTTP/1.1  <--- update the user
Host: mydomain.com
```
Eigentlich sollte es POST /users. (Beachten Sie, dass /users ist plural.) Dies hat die Auswirkungen einen neuen Benutzer zu erstellen und machen es eine untergeordnete Ressource des /users Sammlung.
um fair zu sein, wie man mit Gruppen umgehen, ist eine andere Debatte völlig. GET /users Sinn macht, liest es, wie du willst, aber ich würde in Ordnung sein mit GET /user/<id> oder POST /user (mit einer Nutzlast für die neuen user), denn es liest sich richtig 'get me 5' ist seltsam, aber 'get me Benutzer 5' ist natürlicher. Ich würde wahrscheinlich immer noch fallen auf der Seite der Pluralisierung obwohl 🙂

InformationsquelleAutor ThaDon
162

POST bedeutet "neu anlegen" wie in "Hier ist der Eingang für einen Benutzer zu erstellen, erstellen Sie es für mich".

SETZEN bedeutet "einfügen, ersetzen, wenn Sie bereits vorhanden ist", wie in "Hier sind die Daten für Benutzer 5".

BEITRAG an example.com/users da Sie nicht wissen, die URL, die der Benutzer noch, Sie wollen, dass der server, um es zu schaffen.

STELLEN Sie die example.com/users/id da willst du ersetzen/erstellen einer bestimmten Benutzer.

POSTing zweimal mit den gleichen Daten erstellen Sie zwei identische Benutzer mit verschiedenen ids. Putting zweimal mit den gleichen Daten erstellt der Benutzer die erste und aktualisiert ihn, um den gleichen Zustand beim zweiten mal (keine änderungen). Da Sie am Ende mit dem gleichen Zustand nach SETZEN, egal wie viele Male Sie es ausführen, es heißt, er sei "gleichermaßen wirksam" jedes mal, wenn - idempotent. Dies ist nützlich für die automatische Wiederholung fordert. Nicht mehr "sind Sie sicher, dass Sie möchten, senden', wenn Sie drücken Sie die zurück-Taste des Browsers.

Einer Allgemeinen Beratung ist die Verwendung von POST, wenn Sie benötigen den server, um die Kontrolle der URL-Generierung, wie Sie Ihre Ressourcen. Verwenden Sie SETZEN ansonsten. Lieber über POST.

Schlamperei kann die Ursache haben, dass es allgemein gelehrt, dass es nur zwei Verben, die Sie brauchen: GET und POST. GET zu erhalten, die POST zu ändern. Auch PUT und DELETE erfolgte mit Hilfe der POST. Der Frage, was LEGEN Sie wirklich heißt, 25 Jahre später vielleicht ein Zeichen, das wir gelernt haben falsch auf den ersten. REST Popularität trieb die Menschen zurück zu den Grundlagen, wo müssen wir jetzt verlernen Vergangenheit schlimme Fehler. BEITRAG wurde überstrapaziert und jetzt allgemein gelehrt wird, falsch. Bester Teil: "POSTing zweimal mit den gleichen Daten erstellen Sie zwei identische [Ressourcen]". Großartiger Punkt!
Wie können Sie SETZEN, um einen Eintrag erstellen, indem Sie die ID, wie in deinem Beispiel user 5 wenn es noch nicht existiert? Nicht du meinst update, replace if already exists? oder etwas
Ich meinte, was ich schrieb. Sie legen Benutzer 5, wenn Sie zu /Benutzer/5 und #5 gibt es noch nicht.
Und PUT können auch verwendet werden, um ersetzen der Wert der - Ressource in Ihrer Gesamtheit.
"Lieber über POST - "... die Pflege zu rechtfertigen?

InformationsquelleAutor Alexander Torstling
121

Verwenden Sie den POST zu erstellen und zu aktualisieren. Das ist, wie Ruby on Rails macht es sowieso nicht.
```
PUT    /items/1      #=> update
POST   /items        #=> create
```
POST /items fügt ein neues Element in eine bereits definierte Ressource ('Element'). Es nicht, wie die Antwort, die sagt, "erstellen einer Gruppe." Ich verstehe nicht, warum dies hat 12 Stimmen.
Dies ist ein angemessener Richtwert, aber eine grobe Vereinfachung. Wie die anderen Antworten erwähnt, entweder die Methode kann für beide verwendet werden, zu erstellen und zu aktualisieren.
Ich Stimme mit die Antwort mit eine leichte Modifikation. Verwenden Sie den POST zu erstellen und zu aktualisieren Sie die Ressource vollständig. Für die partielle Aktualisierungen, die wir verwenden können, SETZEN oder PATCH. Können sagen, wir möchten, aktualisieren Sie den status einer Gruppe. Wir können SETZEN /Gruppen/1/status mit dem status der Anfrage-payload-oder PATCH - /Gruppen/1 mit den details zu der Aktion werden in der Nutzlast
Es sollte auch klargestellt werden, dass PUT /items/42 gilt auch für erstellen eine Ressource, aber nur, wenn der AUFTRAGGEBER die Berechtigung der Benennung der Ressource. (Tut Rails ermöglichen einem client diese Namensgebung Privileg?)
ersetzen ist das bessere Wort für die patch-update

InformationsquelleAutor Tim Sullivan
92

Beide werden verwendet für die Datenübertragung zwischen client und server, aber es gibt subtile Unterschiede zwischen Ihnen, das sind:

Analogie:
- SETZEN also nehmen und setzen, wo es war.
- POST als E-mail senden in post office.
Social Media/Network Analogie:
- Post auf social media: wenn wir die post-Meldung, schafft er neue post.
- Setzen(also Bearbeiten), die für die Botschaft, die wir schon Gepostet.
So in der Zusammenfassung: POST für Einsätze, für updates
Nein, REST-Methoden sind nicht DRECK.
Ich würde sagen, für UPSERTS

InformationsquelleAutor Premraj
65

REST ist sehr high-level-Konzept. In der Tat, es gar nicht erwähnen HTTP an alle!

Wenn Sie irgendwelche Zweifel darüber, wie zu implementieren, REST, HTTP, Sie können immer werfen Sie einen Blick auf die Atom Publication Protocol (AtomPub) Spezifikation. AtomPub ist ein standard für das erstellen von RESTful webservices mit HTTP entwickelt wurde, die durch viele HTTP-und REST-Leuchten, mit ein bisschen input von Roy Fielding, dem Erfinder der REST und (co-)Erfinder von HTTP selbst.

In der Tat könnte man sogar in der Lage sein zu verwenden, AtomPub direkt. Während es kam aus der blogging-community, es ist in keiner Weise eingeschränkt zu Bloggen: es ist ein generisches Protokoll für Erholsam Interaktion mit beliebigen (verschachtelt) sind Sammlungen von beliebigen Ressourcen über HTTP. Wenn Sie darstellen können, ist Ihre Anwendung als eine verschachtelte Ansammlung von Ressourcen, dann können Sie nur verwenden, AtomPub und sich keine sorgen darüber, ob PUT oder POST, welche HTTP-Status-Codes zurück und all diese details.

Dies ist, was AtomPub zu sagen hat, über Ressourcen-Erstellung (Abschnitt 9.2):

Hinzufügen von Elementen zu einer Sammlung, die clients senden von POST-requests an den URI der Collection.

Es ist nichts falsch mit dem SETZEN, um Ressourcen anzulegen. Just bewusst sein, dass es bedeutet, dass der client stellt die URL.
Es gibt etwas sehr falsch mit so SETZEN, um Ressourcen anzulegen: der client stellt die URL. Das ist die server-job!
Es ist nicht immer der Fall, dass es die server-job erstellen client-ids. Ich habe immer gesehen, designs, damit Kunden generieren, eine Art UUID als die Ressource-id. Dieses design eignet sich besonders zu vergrössern.
Ich Stimme mit Ihren Standpunkt über die client-IDs erstellt (Anmerkung: alle Systeme wurden von mir seit etwa 2008 muss der client zu erstellen, der die ID eine UUID/Guid). Das bedeutet nicht, dass der AUFTRAGGEBER sollte angeben, die URL.
Ja, wenn die Ressource bereits vorhanden ist, verwenden SETZEN. Jedoch, in fast allen Fällen die Ressourcen, die erstellt werden soll, mit der POST, und der client sollte nicht die URL. Roy Fielding stimmt mit dieser Aussage FWIW: roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

InformationsquelleAutor Jörg W Mittag
58

Die Entscheidung ob PUT oder POST zu erstellen, der eine Ressource auf einem server mit einem HTTP + REST-API basiert auf, wem die URL-Struktur. Dass der client wissen, oder beteiligt sich an der Festlegung, die URL-Struktur ist eine unnötige Kopplung ähnlich wie die unerwünschten Kopplungen, die sich aus SOA. Flucht Arten von Kupplungen ist der Grund, der REST ist so beliebt. Daher die richtige Methode ist POST. Es gibt Ausnahmen von dieser Regel, und Sie treten auf, wenn der Kunde wünscht, die Kontrolle zu behalten über die Lage der Struktur der Ressourcen bereitgestellt werden. Das ist selten und wahrscheinlich etwas anderes bedeutet, ist falsch.

An dieser Stelle werden einige Leute argumentieren, dass, wenn RESTful-URL verwendet werden, hat der Kunde kennt die URL der Ressource und daher ein PUT ist akzeptabel. Nachdem alle, das ist, warum, kanonisch, normalisiert, Ruby on Rails, Django-URLs sind wichtig, Blick auf die Twitter-API ... blah, blah, blah. Diese Menschen müssen verstehen, es gibt keine solche Sache wie eine Restful-URL und Roy Fielding selbst Staaten, die:

Einer REST-API muss nicht fest fixiert Ressourcennamen oder Hierarchien (ein
offensichtliche Kopplung von client und server). Server müssen die Freiheit haben,
zur Kontrolle Ihrer eigenen Namensraum. Anstatt, dass Server anweisen
Kunden, wie Sie zu konstruieren entsprechenden URIs, wie getan wird, im HTML
Formen und URI-templates, die durch die Definition dieser Anweisungen innerhalb der media
Arten-und link-Beziehungen. [Fehler hier bedeutet, dass clients
unter der Annahme einer resource-Struktur durch die out-of-band-Informationen, wie
eine domain-spezifische Norm, die die Daten-orientierte entspricht
RPC-funktionelle Kopplung].

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

Die Idee einer RESTful-URL ist eigentlich eine Verletzung der RUHE für den server zuständig ist, die URL-Struktur und soll frei entscheiden können, wie Sie es verwenden, um zu vermeiden, Kupplung. Wenn das verwirrt, Lesen Sie über die Bedeutung der selbst-Entdeckung auf API-design.

Mit POST, um Ressourcen anzulegen, kommt mit einem design zu berücksichtigen, weil POST ist nicht idempotent. Dies bedeutet, dass die Wiederholung einer POST mehrmals nicht garantieren, dass das gleiche Verhalten jedes mal. Dies schreckt die Menschen zu verwenden, SETZEN Sie das erstellen von Ressourcen, wenn Sie nicht sollte. Sie wissen, es ist falsch (ist die POST für ANLEGEN), aber Sie tun es trotzdem, weil Sie nicht wissen, wie dieses problem zu lösen. Diese Sorge zeigt sich in der folgenden situation:
1. Der AUFTRAGGEBER POST eine neue Ressource auf dem server.
2. Der server verarbeitet die Anfrage und sendet eine Antwort.
3. Der client erhält nie die Antwort.
4. Der server erkennt den client nicht erhalten die Antwort.
5. Der client nicht über eine URL für die Ressource (daher ist keine option) und wiederholt die POST.
6. POST ist nicht idempotent, und der server ...
Schritt 6 ist, wo die Leute Häufig verwirrt über das, was zu tun ist. Es gibt jedoch keinen Grund, erstellen Sie eine Behelfslösung um dieses Problem zu lösen. Stattdessen HTTP verwendet werden kann wie angegeben in RFC 2616 und der server antwortet:

10.4.10 409 Konflikt

Die Anfrage konnte nicht abgeschlossen werden, weil ein Konflikt mit der aktuellen
Zustand der Ressource. Dieser code ist nur zulässig in Situationen, in denen
es wird erwartet, dass der Benutzer in der Lage sein könnte, den Konflikt zu lösen und
die Anforderung erneut senden. Die Antwort Körper SOLLTE genug

Informationen für den Benutzer zu erkennen, die Quelle des Konflikts.
Idealerweise ist die Antwort der Unternehmen hätte genügend Informationen, für die
Benutzer-oder user-agent, das problem zu beheben; jedoch, das könnte nicht sein
möglich und nicht erforderlich.

Konflikte sind die am wahrscheinlichsten auftreten, in Reaktion auf eine PUT-Anfrage. Für
Beispiel, wenn die Versionierung eingesetzt wurden, und die Wesenheit zu SETZEN
enthalten änderungen an einer Ressource, die in Konflikt mit denen, die von einer
früher (third-party) - Anfrage, der server könnte die 409 Antwort
zu zeigen, dass es nicht die Anforderung abzuschließen. In diesem Fall, die
Antwort Person würde wahrscheinlich enthalten eine Liste der Unterschiede zwischen
die zwei Versionen in einem format, definiert durch die Antwort der Content-Type.

Antworten mit Statuscode 409 Conflict ist das richtige Rückgriff weil:
- Durchführung eines POST von Daten, die über eine ID verfügt, das entspricht einer Ressource, die bereits im system ist "ein Konflikt mit dem aktuellen Zustand der Ressource."
- Da der wichtige Teil ist für den client zu verstehen, der server hat die Ressource und die entsprechenden Maßnahmen zu ergreifen. Dies ist eine "situation(en), wo es wird erwartet, dass der Benutzer in der Lage sein könnte, den Konflikt zu lösen und die Anforderung erneut senden."
- Eine Reaktion, die den URL enthält, der die Ressource mit der Konflikt-ID und die entsprechenden Voraussetzungen für die Ressource würden "genug Informationen für den Benutzer-oder user-agent, das problem zu beheben" das ist der ideale Fall die gemäß RFC 2616.
Aktualisierung basiert auf der Veröffentlichung von RFC 7231 zu Ersetzen 2616

RFC 7231 ist entworfen, um zu ersetzen, 2616 und in Abschnitt 4.3.3 beschreibt die Folgen mögliche Antwort für einen BEITRAG

Wenn das Ergebnis der Verarbeitung ein POST entspricht das einer
Darstellung einer existierenden Ressource ist, ein Ursprungs-server umleiten KANN
der user-agent, um diese Ressource durch senden einer 303 (See other) Antwort
mit den vorhandenen Ressourcen-id in das Feld Ort ein. Diese
hat die Vorteile der Bereitstellung der Benutzer-agent-Ressource identifier
und übertragen Sie die Darstellung über eine Methode mehr zugänglich
shared-caching, allerdings auf Kosten eines extra-request, wenn der Benutzer
agent nicht bereits die Darstellung zwischengespeichert.

Es jetzt vielleicht verlockend, schicken Sie einfach eine 303 in dem Fall, dass ein BEITRAG wiederholt wird. Jedoch, das Gegenteil ist wahr. Rückkehr 303 würde nur Sinn machen, wenn mehrere Anfragen (Erstellung verschiedener Ressourcen) wieder den gleichen Inhalt. Ein Beispiel wäre ein "danke für die übermittlung Ihrer Anfrage-Nachricht", dass der client nicht erneut herunterladen, jedes mal. RFC 7231 immer noch behauptet, in Abschnitt 4.2.2, die POST ist nicht idempotent und weiterhin pflegen, die POST sollte verwendet werden, für die erstellen.

Weitere Informationen über diese, Lesen Sie diese Artikel.

Würde ein 409 Conflict Antwort werden Sie den entsprechenden code für etwas, wie der Versuch, erstellen Sie ein neues Konto mit einem Benutzernamen, der bereits existiert? Ich habe mit 409 für versionskonflikte speziell, aber nach der Lektüre Ihre Antwort, ich Frage mich, ob es sollte nicht verwendet werden, für die keine "doppelte" Anfragen.
Ja, in der situation, die Sie beschreiben ", weil ein Konflikt mit dem aktuellen Zustand der Ressource" schlägt der Vorgang fehl. Darüber hinaus ist es vernünftig zu erwarten, dass der Benutzer den Konflikt auflösen, und der Hauptteil der Nachricht muss nur um den Benutzer zu informieren, dass der Benutzername bereits existiert.
können Sie sagen, mehr über den Konflikt-Auflösungsprozess? In diesem Fall, wenn der Benutzername bereits existiert, ist der Kunde erwartet, dass Endbenutzer aufgefordert, für Sie einen anderen Benutzernamen? Was ist, wenn der Kunde tatsächlich versuchen, verwenden Sie den POST zu ändern, der Benutzername? Sollten Anfragen immer noch verwendet werden, für die Parameter zu aktualisieren, während der BEITRAG wird verwendet für die Erstellung von Objekten, ob es ein zu einer Zeit oder mehrere? Danke.
wenn der Benutzername bereits vorhanden ist, dann sollte der client fordert den Benutzer. Ändern Sie den Benutzernamen, vorausgesetzt, der Benutzername ist Teil eine bereits erstellte Ressource, die Bedürfnisse geändert, werden verwendet, weil Sie richtig sind, ist die POST verwendet für erstellen, immer und SETZEN für updates.
Erklärung der Dinge durch kurze und effektive Sprache ist auch eine wünschenswerte Fähigkeiten

InformationsquelleAutor Joshcodes
52

Ich mag diese Ratschläge, von RFC 2616-definition von SETZEN:

Den grundlegenden Unterschied zwischen POST und PUT Anfragen spiegelt sich in der unterschiedlichen Bedeutung der Anfrage-URI. Die URI in einer POST-Anforderung identifiziert die Ressource, die mit der eingeschlossenen Person. Diese Ressource könnte eine Daten-Annahme-Prozess, ein Tor zu einigen anderen Protokoll, oder eine separate Einheit, die akzeptiert Anmerkungen. Im Gegensatz dazu, der URI in eine PUT-Anforderung identifiziert die Entität, eingeschlossen mit den Wunsch-den user-agent weiß, was URI soll und der server MUSS NICHT versuchen auf anwenden, um die Anfrage zu einigen anderen Ressource.

Diese Sticheleien mit den anderen Ratschläge hier, dass ist am besten angewendet, um die Ressourcen, die bereits einen Namen haben, und der POST ist gut für das erstellen eines neuen Objekts aus einer bestehenden Ressource (und lassen Sie den server-Namen).

Interpretiere ich dies, und die idempotenz Anforderungen an STELLEN, bedeuten, dass:
- POST ist gut für das erstellen von neuen Objekten in einer Sammlung (und erstellen nicht sein müssen idempotent)
- SETZEN ist gut für die Aktualisierung der vorhandenen Objekte (und update muss idempotent)
- POST kann auch verwendet werden für nicht-idempotente updates für bestehende Objekte (vor allem, wechselnden Teil eines Objektes ohne Angabe die ganze Sache -- wenn man einmal darüber nachdenkt, erstellen Sie ein neues Mitglied einer Sammlung ist eigentlich ein Spezialfall dieser Art von update, von der Erhebung der Perspektive)
- SETZEN, können auch verwendet werden, für die erstellen, wenn, und nur wenn Sie ermöglichen der Kunde, um den Namen der Ressource. Aber da REST-clients sollen nicht machen Annahmen über die URL-Struktur, ist dies weniger in dem beabsichtigten Geist der Dinge.
"POST kann auch verwendet werden für nicht-idempotente updates für bestehende Objekte (vor allem, wechselnden Teil eines Objektes ohne Angabe die ganze Sache" Das ist, was PATCH ist für

InformationsquelleAutor metamatt
45

Kurz:

SETZEN ist idempotent, wo die Ressource Staat wird dieselbe sein, wenn die gleiche operation ausgeführt, eine Zeit oder mehrere Zeiten.

POST ist nicht idempotent, wo die Ressource Staat kann sich, wenn der Vorgang ausgeführt wird, mehrere Male im Vergleich zu der Ausführung nur ein einziges mal.

Analogie mit der Datenbank-Abfrage -

SETZEN Man sich denken kann, die ähnlich wie "UPDATE STUDENT SET Adresse = "abc" where id="123";

POST Sie sich vorstellen können, so etwas wie "INSERT INTO SCHÜLER(name, Adresse) VALUES ("abc", "xyzzz");

Schüler-Id wird automatisch generiert.

Mit SETZEN, wenn die gleiche Abfrage mehrmals ausgeführt wird oder eine Zeit, die STUDENT-Tabelle Zustand bleibt der gleiche.

Im Falle der POST, wenn die gleiche Abfrage mehrfach ausgeführt wird, dann werden auch mehrere Schüler-Datensätze erhalten, die in der Datenbank erstellt und die Datenbank Statusänderungen auf jede Ausführung von "INSERT" - Abfrage.

HINWEIS: SETZEN, muss eine Ressource location (schon-Ressource) auf die update geschehen muss, in der Erwägung, dass der POST nicht verlangt, dass. Deshalb intuitiv POST gemeint ist, für die Schaffung einer neuen Ressource, in der Erwägung, dass SETZEN ist erforderlich für die Aktualisierung der bereits vorhandenen Ressource.

Einige kommen können, dass updates durchgeführt werden können, mit der POST. Es gibt keine Feste Regel, die für die updates oder das man für das erstellen. Wieder sind diese Konventionen, und intuitiv ich bin geneigt, mit den oben genannten Begründungen und Folgen.

für SETZEN ist ähnlich INSERT-oder UPDATE - Abfrage
tatsächlich LEGTE Sie sich vorstellen können, die ähnlich wie "UPDATE STUDENT SET Adresse = "abc" where id="123"; wäre eine Erklärung für den PATCH. "UPDATE STUDENT SET Adresse = "abc" name="newname" where id="123" wäre eine korrekte Analogie für
Setzen Sie könnte auch verwendet werden, eingefügt werden kann. Zum Beispiel, wenn Sie server entdeckt wurden Sie hochladen möchten, um die gleiche Datei mehrmals, es würde machen Sie Ihre Anfrage idempotent. (Nicht neue Datei-uploads fertig sind).

InformationsquelleAutor bharatj
42

POST ist wie die Entsendung einen Brief an ein Postfach oder an die Buchung eine E-Mail an eine E-Mail-Warteschlange.
SETZEN ist wie wenn Sie ein Objekt in ein cubby Loch oder einen Platz auf einem Regal (hat es eine bekannte Adresse).

POST, du hast das posting an die Adresse der WARTESCHLANGE oder SAMMLUNG. Mit SETZEN, die Sie setzen, um die Adresse des ELEMENTS.

SETZEN ist idempotent. Sie können senden Sie den Antrag 100 mal und es wird nicht von Bedeutung sein. POST ist nicht idempotent. Wenn Sie das senden der Anforderung, 100-mal, erhalten Sie 100 E-Mails oder 100 Briefe in Ihrer post-box.

Allgemeine Regel: wenn Sie wissen, die id oder den Namen des Artikels, verwenden SETZEN. Wenn Sie möchten, dass die id oder den Namen des Elements zugeordnet werden, die von der empfangenden Partei, verwenden Sie den POST.

Nein, STELLEN impliziert, dass Sie wissen, die URL. Wenn Sie wissen nur die ID dann POST mit ID, um die URL.
Die id ist Teil der URL, also ja, verwenden Sie SETZEN, wenn Sie wissen, die URL (die auch die id).
Nein, die URL wird vom server bestimmt und die ID ist nicht unbedingt Teil der URL. Roy Fielding würde sagen, die gleichen oder Sie können einfach nur Lesen seine Arbeit.
ist, dass unter der Annahme REST? In einer ruhigen Architektur, die item-id ist definitiv Teil der URL, wie in: /people/123. Ich mag diese Website für den REST: microformats.org/wiki/rest/urls
die mircoformats link zeigt einen guten Weg für servers, um die Struktur Ihrer URLs, sondern die server legt die URL. Die client-weiter-zu-nicht. Siehe meine Antwort oder der zugehörigen Artikel, wenn Sie das nicht verstehen.

InformationsquelleAutor Homer6
38

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

SETZEN ist lediglich eine Aussage, welche Inhalte sollte der Dienst, von nun an, verwenden Sie zum Rendern die Darstellungen der Ressource identifiziert, durch den AUFTRAGGEBER; POST ist eine Aussage, welche Inhalte sollte der Dienst, von nun an, enthalten (möglicherweise wiederholten), aber es ist bis zu dem server, wie zu identifizieren, die Inhalte.

PUT x (wenn x identifiziert eine Ressource): "Ersetzen Sie den Inhalt der Ressource identifiziert, die durch x mit meinen Inhalten."

PUT x (wenn x nicht zur Identifizierung einer Ressource): "Erstellen Sie eine neue Ressource mit meinem Inhalt und die Nutzung x um es zu identifizieren."

POST x: "Speichern Sie eigene Inhalte, und geben Sie mir eine id, die ich verwenden können, um zu identifizieren eine Ressource (alt oder neu) mit gleichem Inhalt (ggf. gemischt mit anderen Inhalten). Gesagt Ressource sollte identisch sein oder unterstellt, dass die x identifiziert." "y's Ressource untergeordnet ist x's Ressource" ist typisch, aber nicht unbedingt umgesetzt, indem y einem Unterpfad x (z.B. x = /foo und y = /foo/bar) und ändern die Darstellung(en) der x's Ressource zu reflektieren, die die Existenz einer neuen Ressource, z.B. mit einem hyperlink zu y's resource und einige Metadaten. Nur letzteres ist wirklich wichtig, um ein gutes design haben, wie die URLs sind undurchsichtig in RUHE -- man sollte Verwendung von hypermedia statt client-seitige URL-Erstellung, um die traverse der service sowieso.

In RUHE, es gibt keine solche Sache wie eine Ressource mit "Inhalt". Ich beziehe mich als "Inhalte" Daten, die der Dienst verwendet zum Rendern Darstellungen konsequent. Es besteht in der Regel aus einigen verknüpften Zeilen in einer Datenbank oder einer Datei (z.B. einer image-Datei). Es ist bis zu die-Dienstes zum konvertieren den Inhalt in etwas, das der Dienst verwenden kann, wie beispielsweise die Umwandlung einer JSON-Nutzlast, die in SQL-Anweisungen.

Ursprüngliche Antwort (vielleicht leichter zu Lesen):

PUT /something (wenn /something bereits vorhanden ist): "was haben Sie bei der /something und ersetzen Sie es mit dem, was ich Euch geben."

PUT /something (wenn /something nicht bereits vorhanden): "Nehmen Sie, was ich Ihnen und setzen Sie es an /something."

POST /something: "Nehmen Sie, was ich Ihnen und setzen Sie es überall Sie wollen unter /something solange Sie mir Ihre URL wenn du fertig bist."

Aber wie können Sie SETZEN, um eine neue Ressource erstellen wenn es nicht vorhanden ist, während Sie Ihre ID-generation-Methode ist auf den Auto-Increment ? In der Regel ORM ' s wirkt sich die automatische Generierung der ID für Sie, so wie Sie es wollen, in einem BEITRAG zum Beispiel. Bedeutet es, dass, wenn Sie implementieren möchten, SETZEN Sie den rechten Weg, Sie ändern Ihre id auto-generation ? Dies ist peinlich, wenn die Antwort ja ist.
SETZEN ist wie eine Datenbank, "INSERT " ODER" UPDATE " - Anweisung, wo Sie auch die Schlüssel in der Aussage, also nur anwendbar, wo können Sie guarente keine Kollisionen. zB. Ihre domain hat einen "natural key" oder Sie verwenden eine guid. POST ist wie beim einfügen in eine Tabelle ein auto-increment Schlüssel. Sie müssen erzählt werden, durch die Datenbank welche ID es wurde, nachdem es eingefügt wurde. Hinweis: Ihr "INSERT-ODER UPDATE -" ersetzen alle vorherigen Daten (falls vorhanden).
Danke für deine Antwort. Also wenn ich z.B. versuche ein Buch-id 10 mit einem URI: die Bücher STELLEN/10. Wenn die Buch-id 10 nicht vorhanden ist, sollte ich ein Buch mit der id 10 richtig? aber ich kann nicht kontrollieren die Schaffung ID-Zähler, weil es die "auto increment". was sollte ich tun in dieser situation ?
Anderen SETZEN, um eine ID nicht existiert, wird eine Anforderung an den server um eine Ressource zu erstellen. Es ist immer noch auf den server um zu entscheiden, ob er zulassen will, dass. Der server zuständig ist. Sie antwortet mit "Nein. Ich werde das nicht tun". Sie bereits tun, wenn der Benutzer nicht über ausreichende Berechtigungen...etc. Es ist in Ordnung, wenn der server "Nein" zu sagen. REST ist eine Konvention, mit der Sie uns definieren, die Bedeutung der verschiedenen request-Typen ... Sie Ihre server entscheidet, was zu tun ist mit diesen Anforderungen auf der Basis Ihrer business-Logik 🙂 Auch wenn es sagt "Nein", es ist immer noch folgenden REST 🙂

InformationsquelleAutor Jordan
36

Kurze Antwort:

Einfache Faustregel: Verwenden Sie den POST zu erstellen, verwenden Sie SETZEN, zu aktualisieren.

Lange Antwort:

POST:
- POST wird verwendet, um das senden von Daten an server.
- Nützlich, wenn die Ressource mit der URL ist
  unbekannt
SETZEN:
- SETZEN wird verwendet, um den transfer Zustand auf dem server
- Nützlich, wenn eine Ressource-URL bekannt ist
Längere Antwort:

Es zu verstehen, müssen wir uns Fragen, warum war das erforderlich, was waren die Probleme, die GESTELLT wurde, zu lösen versucht, die POST konnte nicht.

Aus einer REST-Architektur-Sicht gibt es keine, was zählt. Wir könnten gelebt haben, ohne dass man als gut. Aber von einem client aus Entwickler-Sicht, die es aus seiner/Ihrer Leben viel einfacher.

Vor zu STELLEN, clients konnte nicht direkt wissen, die URL, die der server erzeugt, oder wenn alle, die es erzeugt hatte jeder, oder ob die Daten gesendet werden, der server ist bereits aktualisiert oder nicht. SETZEN Sie erleichtert, dass die Entwickler all diese Kopfschmerzen. PUT idempotent, LEGTE Griffe, race conditions, und SETZEN erlaubt es dem client, wählen Sie die URL.

Ihre kurze Antwort wäre SEHR falsch. HTTP PUT ist kostenlos wiederholt werden durch HTTP-proxies. Und so, wenn Sie tatsächlich tun Sie SQL INSERT könnte es scheitern zweites mal, was bedeutet, würde es wieder anders ergeben und so würde es sich nicht IDEMPOTENT (was ist der Unterschied zwischen PUT und POST)

InformationsquelleAutor ishandutta2007
35

Ruby on Rails 4.0 wird die Verwendung der "PATCH" - Methode anstelle von PUT-zu tun, partielle updates.

RFC 5789 sagt über PATCH (seit 1995):

Einer neuen Methode ist es notwendig, zur Verbesserung der Interoperabilität und verhindern
Fehler. Die PUT-Methode ist bereits definiert sind, zu überschreiben einer Ressource
mit einer komplett neuen Körper, und kann nicht wiederverwendet werden, machen teilweise änderungen.
Ansonsten, proxies und caches, und auch clients und Servern bekommen kann
verwirrt, als das Ergebnis der operation. POST ist bereits gebraucht, aber
ohne eine Breite Interoperabilität (für eine, es gibt keine standard-Weg, um
entdecken Sie patch-format-Unterstützung). PATCH erwähnt wurde, in früheren HTTP
Spezifikationen, aber nicht vollständig definiert.

"Edge Rails: PATCH ist die neue PV-HTTP-Methode für updates", erklärt er.

InformationsquelleAutor germanlinux
26

Auf die Gefahr wiederholte, was bereits gesagt wurde, scheint es wichtig, daran zu erinnern, dass SETZEN bedeutet, dass die client-Steuerelemente, was die URL wird zu Ende gehen wird, beim erstellen einer Ressource. Also zum Teil die Wahl zwischen SETZEN und POST gehen wird, wie viel Vertrauen Sie den client, um eine korrekte, normierte URL, die kohärent sind mit dem, was Ihre URL-Schema.

Wenn Sie nicht voll Vertrauen der Kunden, das richtige zu tun, es wäre
besser geeignet ist POST ein neues Element erstellen und dann senden Sie die URL an den client zurück, die in der Reaktion.

Ich bin ein bisschen spät, um diese - aber jemandem sagen, dass etwas ähnliches auf einer anderen website kam es zu auf für mich. Wenn Sie eine Ressource und mit auto-increment-ID, wie es ist, "id" anstelle von einem Benutzer zugewiesener name, sollte es ein POST.
Das ist nicht ganz richtig - SETZEN Sie können immer noch eine Ressource, indem er mit einer nicht-kanonischen Namen, so lange, wie in der Antwort gibt der server eine Location header, nicht enthalten die kanonische name der Ressource.
vergessen Sie nicht, dass Sie können viele URIs verweisen auf die gleichen zugrunde liegenden Ressource. Was also Äther ist sagte, fundierte Beratung, kann der client auf eine URL (das könnte mehr sein, semantischen, wie PUT /X-files/series/4/episodes/max) und der server antwortet mit einem URI, der eine kurze canonical-link auf die neue Ressource (dh /X-Ffiles/episodes/91)
das Problem ist die Sorge für die URL-Struktur gehören nicht zu den Kunden. Lesen, um die selbst-Entdeckung (auch ein Teil der REST) kann helfen, machen dies deutlich.
dann nach dieser Logik, ein client sollte niemals verwenden, STELLEN zu schaffen, so sollten Sie nicht besorgt sein mit der Bereitstellung der URL. Naja... es sei denn, die server-URL zu SETZEN, um, wenn der Kunde will, zu legen, um es... so etwas wie "PUT /Kommentare/neue" und die server reagieren könnte "204 /Kommentare/234532", aber das scheint ein bisschen RPC zu mir, der Kunde sollte nur POST /get Kommentare...

InformationsquelleAutor skillet-thief
21

In einer sehr einfachen Art und Weise nehme ich das Beispiel der Facebook-timeline.

Fall 1: Wenn Sie nach etwas auf der timeline, es ist eine frische neue Eintrag. Also in diesem Fall verwenden Sie die POST-Methode, da die Methode POST ist nicht idempotent.

Fall 2: Wenn dein Freund Kommentar auf deinen post das erste mal, dass auch ein neuer Eintrag in der Datenbank, damit die POST-Methode verwendet.

Fall 3: Wenn Ihr Freund bearbeitet seine Bemerkung, in diesem Fall war, hatte Sie die Kommentar-id, so dass Sie aktualisiert einen vorhandenen Kommentar, anstatt einen neuen Eintrag in die Datenbank. Daher wird für diese Art von operation verwenden Sie die PUT-Methode, weil es ist idempotent.*

In einer einzigen Zeile, verwenden Sie POST hinzufügen einen neuen Eintrag in der Datenbank und SETZEN zu update etwas in der Datenbank.

Wenn der Kommentar ist ein Objekt mit einer Eigenschaft wie Benutzer-id, ERSTELLUNGSDATUM, Kommentar, Nachricht, etc. und zur Zeit Bearbeiten Sie nur die Kommentar-Nachricht wird immer aktualisiert, PATCH sollte hier getan werden?
GESTELLT wird von FB um den Kommentar zu aktualisieren, da eine bestehende Ressource aktualisiert wird, und das ist das, was tut PUT (aktualisiert eine Ressource). SETZEN passiert sein idempotent, im Gegensatz zur POST. Ein HTTP-verb wird idempotent betrifft die Fehlerbehandlung, aber nicht diktieren Nutzung. Siehe meine Antwort für eine mehr detaillierte Erklärung: stackoverflow.com/questions/630453/put-vs-post-in-rest/...

InformationsquelleAutor UniCoder
20

Die wichtigste überlegung ist Zuverlässigkeit. Wenn Sie eine POST-Nachricht verloren geht, den Zustand des Systems undefiniert ist. Die automatische Wiederherstellung ist unmöglich. Für Nachrichten, der Zustand ist undefiniert, nur bis die erste erfolgreiche Wiederholung.

Zum Beispiel, kann es nicht eine gute Idee sein, zu erstellen, die Kreditkarten-Transaktionen mit der POST.

Wenn Sie geschehen, um automatisch generierte URI ' s auf Ihre Ressourcen können Sie immer noch SETZEN, indem eine generierte URI (zeigt auf eine leere Ressource) an den client.

Einige weitere überlegungen:
- POST ungültig zwischengespeicherten Kopien der gesamten mit Ressourcen (bessere Konsistenz)
- STELLEN die Antworten werden nicht zwischengespeichert werden, während POST sind (Erfordern Inhalte,-Ort und-Ablauf)
- SETZEN ist weniger unterstützt durch z.B. Java ME, älteren Browsern, firewalls
Das ist falsch. Für die POST, der Staat wird auch undefined nur, bis die erste erfolgreiche Wiederholung. Dann ist entweder der server nimmt die POST (Nachricht nie angekommen), wirft ein 409 Konflikt für eine doppelte ID (Nachricht angekommen ist, Antwort war verloren), oder jede andere gültige Antwort.
Im Allgemeinen ein useragent wäre nicht in der Lage, sicher wiederholen Sie den POST-Vorgang, da die POST-Methode gibt keine Garantie, dass, die beiden Vorgänge haben die gleiche Wirkung wie eine. Die Bezeichnung "ID" hat nichts zu tun mit HTTP. Der URI gibt die Ressource an.
Ein useragent kann "sicher" versuchen einen POST-Vorgang so oft wie es will. Es wird nur ein Duplikat-ID-Fehler (vorausgesetzt, der resource ist eine ID) oder eine Kopie der Daten Fehler (vorausgesetzt, das ist ein Problem und mit der resource nicht IDs).
Knallt mit dem Kopf gegen die Wand. HTTP hat keine Lösung für das problem der Verlässlichkeit, und dieses ist nicht gut verstanden, nicht viel diskutiert, und die einfach nicht berücksichtigt in der Mehrzahl von web-Anwendungen. @Joshcodes ich habe eine Antwort auf diese Frage. Ich im wesentlichen Zustimmen, Hans. Es gibt ein problem.
HTTP verfügt über ein robustes und gut dokumentierte Reihe von Fehlermeldungen. Meine Antwort auf diese Frage (stackoverflow.com/questions/630453/put-vs-post-in-rest/...) beschreibt, wie die Verwendung von http nach Spezifikation auf Konsistenz.

InformationsquelleAutor Hans Malherbe
14

Scheint es immer einige Verwirrung, wenn auf die HTTP-POST-Vergleich die HTTP PUT-Methode für die REST-Dienste. Die meisten Entwickler werden versuchen, Sie zu ordnen CRUD Operationen direkt auf HTTP-Methoden. Ich werde argumentieren, dass dies ist nicht richtig und man kann einfach nicht zuordnen, die CRUD-Konzepte, um die HTTP-Methoden. Das heißt:
```
Create => HTTP PUT
Retrieve => HTTP GET
Update => HTTP POST
Delete => HTTP DELETE
```
Es ist wahr, dass die R(etrieve) und D(elete) der CRUD-Operationen direkt zugeordnet werden können die HTTP-Methoden GET und LÖSCHEN jeweils. Aber die Verwirrung liegt in der C(reate) und U(update) - Operationen. In einigen Fällen kann man mit dem SETZEN für einen erstellen, während in anderen Fällen ein BEITRAG erforderlich sein wird. Die Zweideutigkeit liegt in der definition des HTTP-PUT-Methode im Vergleich zu einer HTTP-POST-Methode.

Gemäß der HTTP-1.1-Spezifikationen der GET, HEAD, DELETE und PUT-Methoden müssen idempotent, und die Methode POST ist nicht idempotent. Das ist zu sagen, dass eine operation ist idempotent, wenn es durchgeführt werden kann, eine Ressource einmal oder viele Male und immer wieder den gleichen Zustand der Ressource. In der Erwägung, dass eine nicht idempotente operation zurückgeben kann geändert Zustand der Ressource aus einer Anfrage zu einem anderen. Daher, in einer nicht-idempotente operation, es gibt keine Garantie, dass man erhalten den gleichen Status einer Ressource.

Basierend auf der obigen definition idempotent, mein nehmen auf die Verwendung der HTTP PUT Methode und mithilfe der HTTP-POST-Methode für die REST-services ist:
Verwenden Sie die HTTP PUT-Methode, wenn:
```
The client includes all aspect of the resource including the unique identifier to uniquely identify the resource. Example: creating a new employee.
The client provides all the information for a resource to be able to modify that resource.This implies that the server side does not update any aspect of the resource (such as an update date).
```
In beiden Fällen werden diese Operationen können durchgeführt werden, mehrere Male mit dem gleichen Ergebnis. Das ist die Ressource nicht geändert werden, indem er die operation mehr als einmal. Also, eine wahre idempotente operation.
Verwenden Sie die HTTP POST-Methode, wenn:
```
The server will provide some information concerning the newly created resource. For example, take a logging system. A new entry in the log will most likely have a numbering scheme which is determined on the server side. Upon creating a new log entry, the new sequence number will be determined by the server and not by the client.
On a modification of a resource, the server will provide such information as a resource state or an update date. Again in this case not all information was provided by the client and the resource will be changing from one modification request to the next. Hence a non idempotent operation.
```
Abschluss

Nicht direkt korrelieren und anzeigen der CRUD-Operationen auf HTTP-Methoden bei REST-services. Die Nutzung einer HTTP PUT-Methode im Vergleich zu einer HTTP-POST-Methode sollte auf der Grundlage der idempotent Aspekt dieser operation. Das heißt, wenn die operation ist idempotent, dann verwenden Sie die HTTP PUT-Methode. Wenn der Betrieb ist nicht idempotent, dann verwenden Sie die HTTP POST-Methode.

Aktualisieren => HTTP-POST : POST ist nicht für die Aktualisierung

InformationsquelleAutor Burhan
14

Neue Leser zu diesem Thema geschlagen werden, durch das endlose Diskussion über das, was Sie sollte tun, und die relative Abwesenheit von lehren aus den Erfahrungen. Die Tatsache, dass RUHE ist "bevorzugt" über der SEIFE ist, glaube ich, eine high-level-lernen aus Erfahrungen, aber Güte müssen wir weitergegangen? Im Jahr 2016. Roy ' s dissertation war im Jahr 2000. Was haben wir entwickelt? War es spass? War es einfach, mit integrieren? Zur Unterstützung? Wird es Griff der Aufstieg von smartphones und schuppige mobile verbindungen?

Nach MIR, real-life-Netzwerke sind unzuverlässig. Anfragen timeout. Verbindungen werden zurückgesetzt. Netzwerke gehen nach unten für Stunden oder Tage zu einer Zeit. Züge fahren in einen Tunnel mit mobilen Benutzern an Bord. Für eine gegebene Anfrage (wie gelegentlich anerkannt in dieser Diskussion) der Antrag kann ins Wasser fallen auf dem Weg, oder kann die Reaktion fallen in das Wasser auf dem Weg zurück. In diesen Bedingungen, Erteilung von PUT -, POST-und DELETE-requests direkt gegen materielle Ressourcen hat immer schien mir ein wenig brutal und naiv.

HTTP tut nichts, um gewährleisten eine zuverlässige Erledigung der Anfrage-Antwort, und das ist gut so, denn dies ist eigentlich Aufgabe der network-aware-Anwendungen. Die Entwicklung einer solchen Anwendung können Sie durch Reifen springen, um zu verwenden, SETZEN Sie statt der POST, dann mehr Reifen zu geben, eine bestimmte Art von Fehler auf dem server, wenn Sie erkennen doppelte Anfragen. Zurück auf dem client, der Sie dann haben zu springen durch Reifen zu interpretieren, diese Fehler, refetch, revalidate und umbuchen.

Oder Sie können dies tun,: betrachten Sie Ihre unsichere Anfragen, wie vergänglich single-user-Ressourcen (nennen wir Sie "Aktionen"). Kunden verlangen eine neue "Aktion" auf eine substantielle Ressource mit einem leeren POST auf die Ressource. POST wird verwendet, nur für diese. Einmal sicher im Besitz der URI des frisch gebackenen action, Setzt der Kunde der unsichere Anfrage an den Aktions-URI nicht die Ziel-Ressource. Die Lösung der Maßnahmen und Aktualisierung der "echten" Ressource ist richtig, die Aufgabe Ihrer API und ist hier entkoppelt von der unzuverlässigen Netzwerk.

Übernimmt der server die business, gibt die Antwort und speichert es gegen die vereinbarten Maßnahmen URI. Wenn etwas schief geht, wiederholt der client die Anfrage (natürliches Verhalten!), und wenn der server bereits gesehen hat, wiederholt er die gespeicherte Antwort und macht nichts anderes.

Werden Sie schnell entdecken, die ähnlichkeit mit dem Versprechen: wir erstellen und Rückkehr der Platzhalter für das Ergebnis, bevor Sie etwas tut. Auch wie ein Versprechen, eine Aktion kann gelingen oder fehlschlagen einer Zeit, aber sein Ergebnis kann abgerufen werden wiederholt.

Besten von allen, geben wir die sendenden und empfangenden Anwendungen eine chance zur Verknüpfung der eindeutig identifizierten Maßnahmen, um Einzigartigkeit in Ihrer jeweiligen Umgebungen. Und wir können beginnen, zu fordern und durchzusetzen!, das verantwortungsvolle Verhalten von Kunden: wiederholen Sie Ihre Anfragen so viel wie Sie wollen, aber gehen Sie nicht erzeugen einer neuen Aktion, bis Sie sind im Besitz einer definitiven Ergebnis aus dem vorhandenen.

Als solche, zahlreiche heikle Probleme Weg. Wiederholte einfügen von Anfragen, die nicht Duplikate erstellen, und wir erstellen Sie nicht die echte Ressource bis wir in den Besitz der Daten. (Datenbank-Spalten können, bleiben nicht-null-Werte zulässt). Wiederholt sich die update-Anfragen nicht schlagen unvereinbar Staaten und nicht überschreiben nachfolgenden änderungen. Kunden (wieder)Holen und seamlessy Prozess die ursprüngliche Bestätigung, aus welchem Grund auch immer (client abgestürzt, Antwort vermisst, usw.).

Aufeinander folgenden delete-requests sehen kann, und der Prozess der ursprünglichen Rückmeldung, ohne auf eine 404-Fehler. Wenn Dinge länger dauern als erwartet, wir Antworten können, vorläufig, und wir haben einen Ort, wo der client überprüfen kann, wieder für das endgültige Ergebnis. Der schönste Teil dieses Musters ist seine Kung-Fu (Panda) - Eigenschaft. Wir nehmen eine Schwäche, die Neigung für die Kunden zu wiederholen, ein verlangen, alle Zeit, die Sie nicht verstehen, die Antwort, und schalten Sie ihn in eine Stärke 🙂

Bevor Sie mir sagen, das ist nicht Erholsam, bitte betrachten Sie die zahlreichen Möglichkeiten, in die REST-Prinzipien eingehalten werden. Kunden nicht konstruieren URLs. Die API bleibt erkennbar, wenn auch mit einer kleinen änderung in der Semantik. HTTP-Verben entsprechend verwendet werden. Wenn Sie denken, dies ist eine große Veränderung umsetzen, ich kann Euch aus Erfahrung sagen, dass es nicht.

Wenn Sie denken, Sie haben riesige Mengen von Daten zu speichern, lassen Sie ' s sprechen Bände: eine typische update-Bestätigung ist ein Bruchteil von einem kilobyte. HTTP aktuell gibt Sie eine minute oder zwei, um zu reagieren, definitiv. Auch wenn Sie nur store-Aktionen für eine Woche, haben Kunden ausreichend Gelegenheit, um aufzuholen. Wenn Sie sehr hohen Stückzahlen, möchten Sie vielleicht einen dedizierten acid-konforme key-value-store, oder eine in-memory-Lösung.

Nicht speichern-Antwort sein, wie die Aufrechterhaltung einer session? Die Ursache wäre (horizontale) Skalierung Probleme.

InformationsquelleAutor bbsimonbb
13

den origin-server erstellen können, die Ressource mit URI

So verwenden Sie POST-und wahrscheinlich, aber nicht erforderlich für die Ressourcen-Erstellung. Sie nicht haben, zu unterstützen. Für mich der POST ist perfekt genug. So ist es eine design-Entscheidung.

Als dein Zitat erwähnt, die Sie verwenden, LEGEN Sie für die Erstellung gibt es keine Ressource zugewiesen werden, um ein IRI und Sie wollen, um eine Ressource zu erstellen sowieso. Zum Beispiel PUT /users/123/password in der Regel ersetzt das alte Passwort mit einem neuen, aber Sie können es verwenden, um ein Passwort erstellen, wenn es nicht schon existieren (zum Beispiel durch frisch registrierte user oder durch die Wiederherstellung von gesperrten Benutzern).

Ich denke, Sie haben es geschafft, eine der wenigen stellen gute Beispiele, wie GESAGT, gut gemacht.

InformationsquelleAutor inf3rno
11

Ich werde das land mit dem folgenden:

SETZEN Sie bezieht sich auf eine Ressource, identifiziert durch die URI. In diesem Fall sind Sie zu aktualisieren. Es ist der Teil, der drei Verben die Bezugnahme auf Ressourcen -- löschen und erhalten die beiden anderen.

POST ist im Grunde ein free-form-Nachricht, mit Ihrer Bedeutung definiert sind, die 'out of band'. Wenn die Nachricht interpretiert werden kann, wie das hinzufügen einer Ressource zu einem Verzeichnis, das wäre OK, aber grundsätzlich müssen Sie verstehen, die Nachricht, die Sie senden (posten), um zu wissen, was passieren wird, mit der Ressource.

Weil PUT und GET und DELETE, beziehen sich auf eine Ressource, Sie sind auch durch definition idempotent.

POST ausführen können, die anderen drei Funktionen, die aber dann die Semantik der Anfrage verloren auf den Vermittler wie Proxys und caches. Dies gilt auch für die Gewährleistung der Sicherheit auf die Ressource, da eine post-URI muss nicht unbedingt die Ressource, die Sie anwenden, (es kann aber).

Einer PUT brauchen wir nicht zu erstellen; der service könnte Fehler, wenn die Ressource nicht bereits angelegt, aber ansonsten ein update. Oder Umgekehrt-es kann die Ressource zu erstellen, aber updates nicht zulassen. Das einzige was Sie tun müssen, zu SETZEN ist, dass es auf eine bestimmte Ressource, und seine Nutzlast ist die Repräsentation der Ressource. Einen erfolgreichen PUT bedeutet (abgesehen von Störungen), die eine BEKOMMEN würde abrufen der gleichen Ressource.

Edit: noch Eine Sache -- eine PUT erstellen können, aber wenn es dann funktioniert, die ID hat eine Natürliche, ID -- AKA eine E-Mail-Adresse. So könnte man, wenn man zweimal, das zweite leg ist ein update der ersten. Dies macht es idempotent.

Wenn die ID generiert wird (einen neuen Mitarbeiter-ID, zum Beispiel), dann die zweite mit der gleichen URL erstellen Sie einen neuen Datensatz, die gegen die Regel idempotent. In diesem Fall ist das verb wäre PFOSTEN, und die Nachricht (nicht resource), wäre das erstellen einer Ressource unter Verwendung der angegebenen Werte in dieser Meldung.

InformationsquelleAutor Gerard ONeill
11

Neben unterschieden vorgeschlagen, die von anderen, möchte ich eine weitere hinzufügen.

In POST Methode können Sie die send-body params in form-data

In SETZEN Methode, die Sie haben zu senden Körper params in x-www-form-urlencoded

Header Content-Type:application/x-www-form-urlencoded

Nach dieser, Sie können nicht senden, Dateien oder multipart-Daten in der SETZEN Methode

BEARBEITEN

Den content-Typ "application/x-www-form-urlencoded" ist ineffizient
für das versenden von großen Mengen an Binärdaten oder text mit
nicht-ASCII-Zeichen. Der Inhaltstyp "multipart/form-data" sein sollte
verwendet für die Abgabe der Formulare, die Dateien enthalten, auch nicht-ASCII-Daten, und
binäre Daten.

Was bedeutet, wenn Sie Einreichen,

Dateien, die nicht-ASCII-Daten und binäre Daten

sollten Sie verwenden POST Methode

Warum wurde das nicht von Ihnen positiv bewertet werden? Wenn true, dies ist eine wichtige Unterscheidung ist es nicht?
Ich stieß darauf bei der Implementierung von API für das Profil-update, das beinhaltet die Benutzer-Profil-Foto hochladen. Dann getestet habe ich es mit dem Briefträger, Ajax -, PHP-curl und laravel 5.6 als backend.

InformationsquelleAutor Rohit Dhiman
9

Die Semantik soll anders sein, "PUT", wie "MAN" sein soll ist idempotent, d.h. Sie können exakt das gleiche PUT-Anfrage mehrfach und das Ergebnis wird sein, als ob Sie ausgeführt, es nur einmal.

Werde ich beschreiben, die Konventionen, die ich denke, sind die meisten weit verbreitet und sind sehr nützlich:

Wenn Sie eine Ressource mit einer bestimmten URL, was passiert, ist, dass es sollte gerettet werden, an die URL, oder etwas entlang jenen Linien.

Wenn Sie POST an eine Ressource mit einer bestimmten URL, oft sind Sie Entsendung einer dazugehörigen information zu dieser URL. Dies bedeutet, dass die Ressource unter der URL bereits vorhanden ist.

Zum Beispiel, wenn Sie möchten, erstellen Sie einen neuen stream, können Sie Sie zu einem anderen URL. Aber wenn Sie wollen, um eine Nachricht zu einem existierenden stream, BEITRAG an die URL.

Als für die änderung der Eigenschaften der Streams, die Sie tun können, dass Sie entweder mit PUT oder POST. Im Grunde, verwenden Sie nur "PUT", wenn die operation ist idempotent - ansonsten verwenden Sie POST.

Beachten Sie jedoch, dass nicht alle modernen Browser unterstützen HTTP-Verben andere als GET oder POST.

Was Sie beschreiben, POST wie ist eigentlich wie PATCH sich Verhalten sollte. POST soll bedeuten, etwas eher zu "Anhängen", wie in "post-mailing-Liste".

InformationsquelleAutor Gregory Magarshak
7

Meisten der Zeit, verwenden Sie diese folgendermaßen:
- POST eine Ressource in einer Sammlung
- SETZEN eine Ressource identifiziert, die durch Sammlung/:id
Beispiel:
- POST /Artikel
- SETZEN /items/1234
In beiden Fällen wird der request-body enthält die Daten für die Ressource erstellt oder aktualisiert werden. Es sollte offensichtlich sein, von der route, Namen, die POST ist nicht idempotent (wenn Sie nennen es 3 mal wird es schaffen 3 Objekte), aber das ist idempotent (wenn Sie nennen es 3-mal das Ergebnis ist das gleiche). PUT ist oft verwendet für "upsert" - operation (erstellen oder aktualisieren), aber man kann immer einen 404 Fehler zurück, wenn Sie nur wollen, um es zu verwenden, zu ändern.

Beachten Sie, dass die POST "entsteht" ein neues element in der Kollektion und SETZEN Sie "ersetzt" ein element an einer bestimmten URL, aber es ist eine sehr gängige Praxis, um zu verwenden, LEGEN Sie für partielle änderungen, das heißt, verwenden Sie es nur zu aktualisieren, die vorhandenen Ressourcen und ändern Sie nur die im Lieferumfang enthalten Felder in den Körper (ignorieren Sie die anderen Felder). Dies ist technisch falsch, wenn Sie wollen, um REST-Puristisch, SETZEN, ersetzen soll die ganze Ressource, und Sie sollten PATCHES für das partielle aktualisieren. Ich persönlich glaube nicht viel Pflege so weit wie das Verhalten ist klar und konsistent über alle API-Endpunkte.

Erinnern, der REST ist ein Satz von Konventionen und Richtlinien zu halten Ihre API einfach. Wenn Sie am Ende mit einem komplizierten work-around, nur um zu überprüfen, die "Erholsamen" - box, dann sind Sie besiegen den Zweck 😉

InformationsquelleAutor tothemario
7

Während es ist wahrscheinlich ein Agnostiker Weg, um diese zu beschreiben, es scheint, in Konflikt mit verschiedenen Aussagen aus den Antworten auf die websites.

Lasst uns sehr klar und direkt hier. Wenn Sie eine .NET Entwickler mit Web-API, die Fakten sind (von 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 Exams 2014 -  UPDATE = PUT, there are **NO** multiple answers for that question period.
```
Sicher, dass Sie nutzen "kann", "POST", um zu aktualisieren, aber Folgen Sie einfach die Konventionen, legte Sie mit Ihrem vorgegebenen Rahmen. In meinem Fall ist es .NET - /Web-API, so PUT für UPDATE gibt es keine Debatte.

Ich hoffe, das hilft, alle Microsoft-Entwickler, Lesen Sie alle Kommentare bei Amazon und Sun/Java-website-links.

InformationsquelleAutor Tom Stickel
6

Wenn Sie sind vertraut mit Datenbank-Operationen,
es gibt
1. Wählen Sie
2. Einfügen
3. Update
4. Löschen
5. Merge (Update, falls bereits vorhanden, sonst insert)
Benutze ich PUT für Merge und update wie Operationen und verwenden POST für Einfügungen.

InformationsquelleAutor Rajan
6

Hier ist eine einfache Regel:

SETZEN, um eine URL sollte verwendet werden, zu aktualisieren oder erstellen Sie die Ressource, die sich zu diesem URL.

POST, um eine URL sollte verwendet werden, zu aktualisieren oder erstellen Sie eine Ressource, die sich bei einigen anderen ("untergeordnet") URL, oder ist nicht lokalisierbar über HTTP.

PUT ist nicht für das update, es ist für ersetzen, beachten Sie, dass zu erstellen, Sie ersetzen nichts mit etwas. Der POST ist absolut nicht für das update in jeder Form der form.
Funktioniert der http-spec sagen? Oder Sie stützen Ihren Kommentar auf etwas anderes?
Es ist einfach der gesunde Menschenverstand, wie du das update etwas, wenn Sie nicht wissen, was es ist, die Sie aktualisieren? POST ist für die Erstellung einer neuen Ressource.
thecoshman -- Sie missbrauchen Semantik hier -- replace kann ein update wenn es die gleiche Ressource mit ein paar Unterschiede. Ein ersetzen ist nur gültig gesetzt, wenn ersetzen wird verwendet, um die gleichen Ressourcen. Ersetzen mit eine neue und andere Ressource ist ungültig (entfernen Sie alte und neue hinzufügen?), vor allem, wenn der "neue" Ressource nicht haben ein natürliches ID. POST, OTOH, ist etwas, das erstellen, aktualisieren, ersetzen und löschen-mit der post hängt davon ab, ob oder nicht es ist eine Botschaft zu interpretieren, wie z.B. "Rabatt", die kann oder kann nicht ändern Sie die Ressource, die je nach Logik.
Für Ihren zweiten Kommentar -- wie Sie 'bekommen' die Ressource, ändern Sie die Felder, die Sie benötigen, und setzen Sie ihn dann zurück? Oder wie wäre es, wenn die Ressource kommt aus einer anderen Quelle, sondern benutzt eine Natürliche-ID (external ID) -- setzen würde natürlich aktualisieren Sie die Ressource an der URL, wenn die Originaldaten geändert.

InformationsquelleAutor Adam Griffiths
5

In der Praxis POST funktioniert gut für die Erstellung von Ressourcen. Die URL der neu erstellten Ressource zurückgegeben werden sollen, die in der Location-response-header. LEGEN sollte verwendet werden, für die Aktualisierung einer Ressource vollständig. Bitte verstehen Sie, dass diese sind die besten Methoden beim entwerfen eines RESTful API. HTTP-Spezifikation als solche nicht einschränken, mit PUT/POST mit ein paar Einschränkungen für die Erstellung/Aktualisierung von Ressourcen. Werfen Sie einen Blick auf http://techoctave.com/c7/posts/71-twitter-rest-api-dissected, fasst die best practices.

Für die meisten Teil, vom Lesen über all diesem Lärm, Sie scheinen auf den ball. Ich würde aber sagen, wir beziehen sollten, um so die replace-Methode, anstatt das erstellen/aktualisieren. Ich denke, dass es besser beschreibt, was es tut.

InformationsquelleAutor java_geek

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.

Zusammenfassung:

Erstellen:

SETZEN

POST

Update:

SETZEN

Erklärung:

Beispiele:

Spec:

POST

SETZEN

Referenz:

Analogie mit der Datenbank-Abfrage -