POST /expense-report

PUT  /expense-report/10929

POST /users HTTP/1.1

POST /users/john HTTP/1.1

PUT /users/john HTTP/1.1

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

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

PUT	POST
Bestaande resource vervangen of maken als resource niet bestaat. www.example.com/com/customer/{customerId} www.example.com/com/customer/123/order/{orderId} Identificatie wordt gekozen door de klant.	Het creëren van nieuwe middelen en ondergeschikte middelen, b.v. een bestand is ondergeschikt aan een map die het bevat of een rij is ondergeschikt aan een databasetabel. www.example.com/com/customer/ www.example.com/com/customer/123/order/ id wordt geretourneerd door server
Idempotent, d.w.z. als u een resource twee keer PUT heeft, heeft dit geen effect. Voorbeeld: Doe het zo vaak als je wilt, het resultaat zal hetzelfde zijn. x=1;	POST is noch veilig, noch idempotent. Voorbeeld: x++;
Werkt als specifiek	Werkt als abstractief
Als u een bron maakt of bijwerkt met behulp van PUT en vervolgens dezelfde aanroep opnieuw doet, is de bron er nog steeds en heeft deze nog steeds dezelfde status als bij de eerste aanroep.	Het maken van twee identieke POST-verzoeken zal hoogstwaarschijnlijk resulteren in twee bronnen die dezelfde informatie bevatten.

---

Antwoord 8, autoriteit 3%

Gebruik POST om te creëren en PUT om te updaten. Zo doet Ruby on Rails het in ieder geval.

PUT    /items/1      #=> update
POST   /items        #=> create

---

Antwoord 9, autoriteit 2%

REST is een zeer concept op hoog niveau. Er wordt zelfs helemaal geen melding gemaakt van HTTP!

Als je twijfelt over hoe je REST in HTTP moet implementeren, kun je altijd een kijkje nemen op de Atom Publication Protocol (AtomPub)-specificatie. AtomPub is een standaard voor het schrijven van RESTful-webservices met HTTP die is ontwikkeld door veel HTTP- en REST-grootheden, met wat input van Roy Fielding, de uitvinder van REST en (mede)uitvinder van HTTP zelf.

In feite kunt u AtomPub zelfs rechtstreeks gebruiken. Hoewel het uit de bloggemeenschap komt, is het op geen enkele manier beperkt tot bloggen: het is een generiek protocol voor REST-interactie met willekeurige (geneste) verzamelingen van willekeurige bronnen via HTTP. Als u uw toepassing kunt weergeven als een geneste verzameling bronnen, kunt u AtomPub gewoon gebruiken en hoeft u zich geen zorgen te maken over het gebruik van PUT of POST, welke HTTP-statuscodes u moet retourneren en al die details.

Dit is wat AtomPub te zeggen heeft over het maken van bronnen (paragraaf 9.2):

Om leden aan een collectie toe te voegen, sturen klanten POST-verzoeken naar de URI van de collectie.

---

Antwoord 10

De beslissing om PUT of POST te gebruiken om een ​​bron op een server met een HTTP + REST API te maken, is gebaseerd op wie de eigenaar is van de URL-structuur. De klant laten weten of meewerken aan het definiëren , is de URL-struct een onnodige koppeling vergelijkbaar met de ongewenste koppelingen die voortkwamen uit SOA. Ontsnappen aan soorten koppelingen is de reden dat REST zo populair is. Daarom is de juiste methode om te gebruiken POST. Er zijn uitzonderingen op deze regel en deze treden op wanneer de klant de controle wil behouden over de locatiestructuur van de middelen die hij inzet. Dit komt zelden voor en betekent waarschijnlijk dat er iets anders mis is.

Op dit punt zullen sommige mensen beweren dat als RESTful-URL’s worden gebruikt, de client de URL van de bron kent en daarom is een PUT acceptabel. Dit is tenslotte de reden waarom canonieke, genormaliseerde, Ruby on Rails, Django-URL’s belangrijk zijn, kijk naar de Twitter API – blah blah blah. Die mensen moeten begrijpen er bestaat niet zoiets als een Restful-URL en dat Roy Fielding zelf stelt dat:

Een REST API mag geen vaste resourcenamen of hiërarchieën definiëren (een
duidelijke koppeling van client en server). Servers moeten de vrijheid hebben
om hun eigen naamruimte te beheren. Sta in plaats daarvan toe dat servers instructies geven
clients over het maken van geschikte URI’s, zoals in HTML
formulieren en URI-sjablonen, door die instructies in media te definiëren
typen en linkrelaties. [Fout hier houdt in dat klanten zijn
uitgaande van een resourcestructuur vanwege out-of-band informatie, zoals:
een domeinspecifieke standaard, het datageoriënteerde equivalent van:
RPC’s functionele koppeling].

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

Het idee van een RESTful-URL is eigenlijk een schending van REST, aangezien de server de leiding heeft over de URL-structuur en vrij moet zijn om te beslissen hoe deze te gebruiken om koppeling te voorkomen. Als dit je in de war brengt, lees je over het belang van zelfontdekking op API-ontwerp.

Het gebruik van POST om bronnen te maken komt met een ontwerpoverweging, omdat POST niet idempotent is. Dit betekent dat het meerdere keren herhalen van een POST niet elke keer hetzelfde gedrag garandeert. Dit schrikt mensen af ​​om PUT te gebruiken om bronnen te creëren terwijl ze dat niet zouden moeten doen. Ze weten dat het verkeerd is (POST is voor CREATE) maar ze doen het toch omdat ze niet weten hoe ze dit probleem moeten oplossen. Deze zorg wordt aangetoond in de volgende situatie:

1. De client POST een nieuwe bron naar de server.
2. De server verwerkt het verzoek en stuurt een antwoord.
3. De klant ontvangt nooit het antwoord.
4. De server weet niet dat de client het antwoord niet heeft ontvangen.
5. De client heeft geen URL voor de bron (daarom is PUT geen optie) en herhaalt de POST.
6. POST is niet idempotent en de server

Stap 6 is waar mensen vaak in de war raken over wat ze moeten doen. Er is echter geen reden om een ​​kludge te creëren om dit probleem op te lossen. In plaats daarvan kan HTTP worden gebruikt zoals gespecificeerd in RFC 2616 en de server antwoordt:

10.4.10 409 Conflict

Het verzoek kon niet worden voltooid vanwege een conflict met de huidige
staat van de bron. Deze code is alleen toegestaan ​​in situaties waarin:
er wordt verwacht dat de gebruiker het conflict kan oplossen en
de aanvraag opnieuw indienen. De reactietekst MOET genoeg bevatten

informatie voor de gebruiker om de bron van het conflict te herkennen.
Idealiter zou de responsentiteit voldoende informatie bevatten voor de
gebruiker of user-agent om het probleem op te lossen; maar dat is misschien niet zo
mogelijk en niet vereist.

Conflicten treden meestal op als reactie op een PUT-verzoek. Voor
bijvoorbeeld als versiebeheer werd gebruikt en de entiteit PUT . is
opgenomen wijzigingen in een bron die in strijd zijn met die gemaakt door een
eerder verzoek (van derden), kan de server het 409-antwoord gebruiken
om aan te geven dat het verzoek niet kan worden voltooid. In dit geval is de
antwoord-entiteit zou waarschijnlijk een lijst bevatten van de verschillen tussen:
de twee versies in een formaat gedefinieerd door het antwoord Content-Type.

Reageren met de statuscode 409 Conflict is de juiste oplossing, omdat:

• Het uitvoeren van een POST van gegevens met een ID die overeenkomt met een bron die al in het systeem aanwezig is, is ‘een conflict met de huidige status van de bron’.
• Omdat het belangrijkste is dat de client begrijpt dat de server over de middelen beschikt en de juiste actie onderneemt. Dit is een situatie waarin wordt verwacht dat de gebruiker het conflict kan oplossen en het verzoek opnieuw kan indienen.
• Een antwoord dat de URL van de bron met de conflicterende ID en de juiste voorwaarden voor de bron bevat, zou “voldoende informatie voor de gebruiker of user-agent bieden om het probleem op te lossen”, wat het ideale geval is volgens RFC 2616.

li>

Update gebaseerd op release van RFC 7231 ter vervanging van 2616

RFC 7231 is ontworpen om 2616 te vervangen en in Sectie 4.3.3 beschrijft de volgende mogelijke reactie voor een POST

Als het resultaat van het verwerken van een POST gelijk zou zijn aan a
weergave van een bestaande bron, een oorspronkelijke server KAN omleiden
de user agent naar die bron door een 303 (Zie Overige) reactie te sturen
met de identificatie van de bestaande resource in het veld Locatie. Deze
heeft de voordelen om de user-agent een resource-ID te geven
en het overbrengen van de representatie via een methode die beter geschikt is voor
gedeelde caching, maar tegen een extra verzoek als de gebruiker
agent heeft de representatie nog niet in de cache opgeslagen.

Het kan nu verleidelijk zijn om gewoon een 303 terug te sturen in het geval dat een POST wordt herhaald. Het tegendeel is echter waar. Het retourneren van een 303 heeft alleen zin als meerdere aanmaakverzoeken (die verschillende bronnen maken) dezelfde inhoud retourneren. Een voorbeeld is een “bedankt voor het verzenden van uw verzoekbericht” dat de klant niet elke keer opnieuw hoeft te downloaden. RFC 7231 stelt in paragraaf 4.2.2 nog steeds dat POST niet idempotent mag zijn en blijft volhouden dat POST moet worden gebruikt voor het maken.

Lees voor meer informatie hierover artikel.

---

Antwoord 11

Ik hou van dit advies, van RFC 2616’s definitie van PUT:

Het fundamentele verschil tussen de POST- en PUT-verzoeken wordt weerspiegeld in de verschillende betekenis van de Request-URI. De URI in een POST-verzoek identificeert de resource die de ingesloten entiteit zal afhandelen. Die bron kan een gegevensacceptatieproces zijn, een gateway naar een ander protocol of een afzonderlijke entiteit die annotaties accepteert. Daarentegen identificeert de URI in een PUT-verzoek de entiteit die bij het verzoek is gevoegd — de user-agent weet welke URI bedoeld is en de server MOET NIET proberen het verzoek toe te passen op een andere bron.

Dit komt overeen met het andere advies hier, dat PUT het beste kan worden toegepast op bronnen die al een naam hebben, en POST is goed voor het maken van een nieuw object onder een bestaande bron (en laat de server het een naam geven).

Ik interpreteer dit, en de idempotentievereisten op PUT, als volgt:

• POST is goed voor het maken van nieuwe objecten onder een verzameling (en create hoeft niet idempotent te zijn)
• PUT is goed voor het updaten van bestaande objecten (en update moet idempotent zijn)
• POST kan ook worden gebruikt voor niet-idempotente updates van bestaande objecten (vooral, een deel van een object wijzigen zonder het hele ding te specificeren – als je erover nadenkt, is het maken van een nieuw lid van een verzameling eigenlijk een speciaal geval van dit soort updates, vanuit het perspectief van de collectie)
• PUT kan ook worden gebruikt voor maken als en alleen als u de client toestaat de bron een naam te geven. Maar aangezien het niet de bedoeling is dat REST-clients veronderstellingen maken over de URL-structuur, is dit minder in de beoogde geest van de dingen.

---

Antwoord 12

Kortom:

PUT is idempotent, waarbij de bronstatus hetzelfde is als dezelfde bewerking een keer of meerdere keren wordt uitgevoerd.

POST is niet-idempotent, waarbij de bronstatus anders kan worden als de bewerking meerdere keren wordt uitgevoerd in vergelijking met één keer uitvoeren.

Analogie met databasequery

PUT Je kunt denken aan “UPDATE STUDENT SET address = "abc" waar id="123";

POST Je kunt iets bedenken als "INSERT INTO STUDENT(naam, adres) VALUES("abc", "xyzzz");

Student-ID wordt automatisch gegenereerd.

Met PUT blijft de STUDENT-tabelstatus hetzelfde als dezelfde query meerdere keren of één keer wordt uitgevoerd.

In het geval van POST, als dezelfde query meerdere keren wordt uitgevoerd, worden er meerdere studentrecords in de database gemaakt en verandert de databasestatus bij elke uitvoering van een "INSERT" vraag.

OPMERKING: PUT heeft een bronlocatie (reeds-bron) nodig waarop de update moet plaatsvinden, terwijl POST dat niet vereist. Daarom is POST intuïtief bedoeld voor het maken van een nieuwe bron, terwijl PUT nodig is voor het bijwerken van de reeds bestaande bron.

Sommigen zouden kunnen bedenken dat updates kunnen worden uitgevoerd met POST. Er is geen harde regel welke u moet gebruiken voor updates of welke u moet gebruiken om te maken. Nogmaals, dit zijn conventies, en intuïtief ben ik geneigd tot de bovengenoemde redenering en volg deze.

---

Antwoord 13

POST is als het plaatsen van een brief in een mailbox of het plaatsen van een e-mail in een e-mailwachtrij.
PUT is hetzelfde als wanneer je een object in een hokje of een plaats op een plank plaatst (het heeft een bekend adres).

Met POST post je naar het adres van de WACHTRIJ of COLLECTIE. Met PUT zet je naar het adres van het ITEM.

PUT is idempotent. U kunt het verzoek 100 keer verzenden en het maakt niet uit. POST is niet idempotent. Als u het verzoek 100 keer verstuurt, ontvangt u 100 e-mails of 100 brieven in uw brievenbus.

Een algemene regel: als je de id of naam van het item weet, gebruik dan PUT. Als u wilt dat de id of naam van het item wordt toegewezen door de ontvangende partij, gebruikt u POST.

---

Antwoord 14

Nieuw antwoord (nu ik REST beter begrijp):

PUT is slechts een verklaring van welke inhoud de service vanaf nu zou moeten gebruiken om representaties weer te geven van de bron die door de klant is geïdentificeerd; POST is een verklaring van welke inhoud de service vanaf nu zou moeten bevatten (mogelijk gedupliceerd), maar het is aan de server hoe die inhoud te identificeren.

PUT x (als x een bron): “Vervang de inhoud van de bron geïdentificeerd door x door mijn inhoud.”

PUT x (als x een bron niet identificeert): “Maak een nieuwe bron met mijn inhoud en gebruik x om deze te identificeren .”

POST x: “Bewaar mijn inhoud en geef me een identifier die ik kan gebruiken om een ​​bron (oud of nieuw) te identificeren die genoemde inhoud bevat (mogelijk gemengd met andere inhoud). Deze bron zou moeten zijn identiek of ondergeschikt aan dat wat x identificeert.” “De bron van y is ondergeschikt aan de bron van x” wordt meestal, maar niet noodzakelijkerwijs geïmplementeerd door van y een subpad van x te maken (bijv. x = /foo en y = /foo/bar) en het wijzigen van de weergave (s) van de bron van x om het bestaan ​​van een nieuwe bron weer te geven, bijv met een hyperlink naar de bron van y en enkele metadata. Alleen dit laatste is echt essentieel voor een goed ontwerp, aangezien URL’s ondoorzichtig zijn in REST – je zou in plaats daarvan hypermedia moeten gebruiken van client-side URL-constructie om de service toch te doorkruisen.

In REST bestaat er niet zoiets als een bron die “inhoud” bevat. Ik verwijs als ‘inhoud’ naar gegevens die de service gebruikt om consistente weergaven weer te geven. Het bestaat meestal uit een aantal gerelateerde rijen in een database of een bestand (bijvoorbeeld een afbeeldingsbestand). Het is aan de dienst om de inhoud van de gebruiker om te zetten in iets dat de dienst kan gebruiken, b.v. het omzetten van een JSON-payload in SQL-statements.

Oorspronkelijk antwoord (misschien makkelijker te lezen):

PUT /something (als /something al bestaat): “Neem wat je hebt bij /something en vervang het door wat ik geef jij.”

PUT /something (als /something nog niet bestaat): “Neem wat ik je geef en zet het op /something. “

POST /something: “Neem wat ik je geef en zet het waar je maar wilt onder /something zolang je me de URL geeft als je klaar bent. “

---

Antwoord 15

Kort antwoord:

Eenvoudige vuistregel: gebruik POST om te creëren, gebruik PUT om te updaten.

Lang antwoord:

POST:

• POST wordt gebruikt om gegevens naar de server te sturen.
• Nuttig wanneer de URL van de bron is
  onbekend

PUT:

• PUT wordt gebruikt om de status naar de server over te dragen
• Nuttig als de URL van een bron bekend is

Langer antwoord:

Om het te begrijpen moeten we ons afvragen waarom PUT nodig was, wat waren de problemen die PUT probeerde op te lossen die POST niet kon.

Vanuit het oogpunt van een REST-architectuur is er niets dat ertoe doet. We hadden ook zonder PUT kunnen leven. Maar vanuit het oogpunt van een klantontwikkelaar maakte het zijn/haar leven een stuk eenvoudiger.

Voorafgaand aan PUT konden clients niet direct weten welke URL de server heeft gegenereerd, of alles wat deze heeft gegenereerd, en of de gegevens die naar de server moeten worden verzonden, al zijn bijgewerkt of niet. PUT heeft de ontwikkelaar van al deze kopzorgen verlost. PUT is idempotent, PUT handelt racecondities af en PUT laat de klant de URL kiezen.

---

Antwoord 16

Ruby on Rails 4.0 gebruikt de ‘PATCH’-methode in plaats van PUT om gedeeltelijke updates uit te voeren.

RFC 5789 zegt over PATCH (sinds 1995):

Er is een nieuwe methode nodig om de interoperabiliteit te verbeteren en te voorkomen
fouten. De PUT-methode is al gedefinieerd om een ​​resource te overschrijven
met een compleet nieuwe body, en kan niet opnieuw worden gebruikt om gedeeltelijke wijzigingen aan te brengen.
Anders kunnen proxy’s en caches, en zelfs clients en servers,
verward over het resultaat van de operatie. POST wordt al gebruikt, maar
zonder brede interoperabiliteit (ten eerste is er geen standaardmanier om
ondersteuning voor patchformaten ontdekken). PATCH werd genoemd in eerdere HTTP
specificaties, maar niet volledig gedefinieerd.

“Edge Rails: PATCH is de nieuwe primaire HTTP-methode voor updates” legt het uit.

---

Antwoord 17

Met het risico om te herhalen wat al is gezegd, lijkt het belangrijk om te onthouden dat PUT impliceert dat de klant bepaalt wat de URL uiteindelijk gaat worden, bij het maken van een bron. Dus een deel van de keuze tussen PUT en POST zal gaan over hoeveel u erop kunt vertrouwen dat de klant correcte, genormaliseerde URL verstrekt die zijn coherent met wat uw URL-schema ook is.

Als je de klant er niet volledig op kunt vertrouwen dat hij het juiste doet, zou dat zo zijn
meer geschikt om POST te gebruiken om een ​​nieuw item te maken en vervolgens de URL terug te sturen naar de klant in het antwoord.

---

Antwoord 18

Op een heel eenvoudige manier neem ik het voorbeeld van de Facebook-tijdlijn.

Geval 1: Als je iets op je tijdlijn plaatst, is het een fris nieuw bericht. Dus in dit geval gebruiken ze de POST-methode omdat de POST-methode niet-idempotent is.

Geval 2: Als je vriend de eerste keer op je bericht reageert, wordt er ook een nieuw item in de database gemaakt, dus de POST-methode die wordt gebruikt.

Geval 3: Als je vriend zijn opmerking bewerkt, in dit geval, hadden ze een opmerking-ID, dus zullen ze een bestaande opmerking bijwerken in plaats van een nieuw item in de database te maken. Gebruik daarom voor dit type bewerking de PUT-methode omdat deze idempotent is.*

Gebruik in één regel POST om een nieuw item toe te voegen aan de database en PUT om bij te werken iets in de database.

---

Antwoord 19

De belangrijkste overweging is betrouwbaarheid. Als een POST-bericht verloren gaat, is de status van het systeem niet gedefinieerd. Automatisch herstel is onmogelijk. Voor PUT-berichten is de status alleen ongedefinieerd tot de eerste succesvolle poging.

Het is bijvoorbeeld misschien geen goed idee om creditcardtransacties te maken met POST.

Als je automatisch gegenereerde URI’s op je bron hebt staan, kun je nog steeds PUT gebruiken door een gegenereerde URI (verwijzend naar een lege bron) door te geven aan de client.

Enkele andere overwegingen:

• POST maakt kopieën in de cache ongeldig van de volledige bron (betere consistentie)
• PUT-reacties kunnen niet in de cache worden opgeslagen, terwijl POST-reacties dat wel zijn (inhoudslocatie en vervaldatum vereist)
• PUT wordt minder ondersteund door b.v. Java ME, oudere browsers, firewalls

---

Antwoord 20

Naast de door anderen gesuggereerde verschillen, wil ik er nog een toevoegen.

In de POST methode kun je body parameters in form-data

sturen

In de PUT methode moet je body parameters in x-www-form-urlencoded

sturen

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

Volgens dit kunt u geen bestanden of meerdelige gegevens verzenden met de PUT-methode

BEWERKEN

Het inhoudstype “application/x-www-form-urlencoded” is inefficiënt
voor het verzenden van grote hoeveelheden binaire gegevens of tekst met:
niet-ASCII-tekens. Het inhoudstype “multipart/form-data” moet zijn
gebruikt voor het indienen van formulieren die bestanden, niet-ASCII-gegevens bevatten, en
binaire gegevens.

Wat betekent dat als je moet indienen

bestanden, niet-ASCII-gegevens en binaire gegevens

u moet de POST-methode

. gebruiken

---

Antwoord 21

Lezers die nieuw zijn in dit onderwerp zullen worden getroffen door de eindeloze discussie over wat je zou moet doen, en de relatieve afwezigheid van lessen uit ervaring. Het feit dat REST “de voorkeur heeft” boven SOAP, is, denk ik, een leerervaring op hoog niveau, maar goed, moeten we vanaf dat moment vooruitgang hebben geboekt? Het is 2016. Roy’s proefschrift was in 2000. Wat hebben we ontwikkeld? Was het leuk? Was het makkelijk om mee te integreren? Ondersteunen? Zal het de opkomst van smartphones en haperende mobiele verbindingen aankunnen?

Volgens ME zijn echte netwerken onbetrouwbaar. Verzoek time-out. Verbindingen worden gereset. Netwerken vallen uren of dagen achter elkaar uit. Treinen gaan tunnels in met mobiele gebruikers aan boord. Voor een bepaald verzoek (zoals af en toe erkend in deze discussie) kan het verzoek onderweg in het water vallen, of het antwoord kan op de terugweg in het water vallen. Onder deze omstandigheden is het direct afgeven van PUT-, POST- en DELETE-verzoeken tegen inhoudelijke bronnen mij altijd een beetje brutaal en naïef overkomen.

HTTP doet niets om een ​​betrouwbare voltooiing van het verzoek-antwoord te garanderen, en dat is prima, want dit is de taak van netwerkbewuste toepassingen. Als je zo’n applicatie ontwikkelt, kun je door hoepels springen om PUT te gebruiken in plaats van POST, en dan meer hoepels om een ​​bepaald soort fout op de server te geven als je dubbele verzoeken detecteert. Terug bij de klant moet je door hoepels springen om deze fouten te interpreteren, opnieuw op te halen, opnieuw te valideren en opnieuw te posten.

Of u kunt dit doen: beschouw uw onveilige verzoeken als kortstondige bronnen voor één gebruiker (laten we ze acties noemen). Klanten vragen een nieuwe “actie” aan op een inhoudelijke resource met een lege POST naar de resource. POST wordt alleen hiervoor gebruikt. Eenmaal veilig in het bezit van de URI van de nieuw aangemaakte actie, plaatst de client het onveilige verzoek in de actie-URI, niet de doelbron. Het oplossen van de actie en het bijwerken van de “echte” bron is de taak van uw API en wordt hier losgekoppeld van het onbetrouwbare netwerk.

De server doet het werk, retourneert het antwoord en slaat het op tegen de afgesproken actie-URI. Als er iets misgaat, herhaalt de client het verzoek (natuurlijk gedrag!), en als de server het al heeft gezien, herhaalt het de opgeslagen reactie en doet niets anders.

Je zult snel de gelijkenis met beloften zien: we maken en retourneren de tijdelijke aanduiding voor het resultaat voordat we iets doen. Evenals een belofte, kan een actie een keer slagen of mislukken, maar het resultaat kan herhaaldelijk worden opgehaald.

Het beste van alles is dat we verzendende en ontvangende applicaties de kans geven om de uniek geïdentificeerde actie te koppelen aan uniciteit in hun respectieve omgevingen. En we kunnen beginnen met het eisen en afdwingen van verantwoord gedrag van klanten: herhaal je verzoeken zoveel je wilt, maar ga pas een nieuwe actie genereren als je een definitief resultaat van de bestaande hebt.

Als zodanig verdwijnen tal van netelige problemen. Herhaalde invoegverzoeken zullen geen duplicaten creëren, en we creëren de echte bron pas als we in het bezit zijn van de gegevens. (databasekolommen kunnen niet-nullable blijven). Herhaalde updateverzoeken zullen geen incompatibele statussen bereiken en latere wijzigingen niet overschrijven. Klanten kunnen de originele bevestiging om welke reden dan ook (opnieuw) ophalen en naadloos verwerken (client crashte, reactie ontbrak, enz.).

Opeenvolgende verwijderingsverzoeken kunnen de oorspronkelijke bevestiging zien en verwerken, zonder dat er een 404-fout optreedt. Als het langer duurt dan verwacht, kunnen we voorlopig reageren en hebben we een plek waar de klant terug kan komen voor het definitieve resultaat. Het mooiste van dit patroon is de eigenschap Kung-Fu (Panda). We nemen een zwak punt, de neiging van klanten om een ​​verzoek te herhalen wanneer ze het antwoord niet begrijpen, en veranderen het in een sterkte 🙂

Alvorens mij te vertellen dat dit niet REST is, moet u rekening houden met de talrijke manieren waarop REST-principes worden gerespecteerd. Klanten maken geen URL’s. De API blijft vindbaar, zij het met een kleine verandering in de semantiek. HTTP-werkwoorden worden op de juiste manier gebruikt. Als je denkt dat dit een enorme verandering is om door te voeren, kan ik je uit ervaring vertellen dat dit niet het geval is.

Als je denkt dat je enorme hoeveelheden gegevens moet opslaan, laten we het dan over volumes hebben: een typische updatebevestiging is een fractie van een kilobyte. HTTP geeft je momenteel een minuut of twee om definitief te reageren. Ook als je acties maar een week opslaat, hebben klanten ruimschoots de kans om bij te praten. Als u zeer hoge volumes hebt, wilt u misschien een speciale zuur-conforme sleutelwaardeopslag of een in-memory-oplossing.

---

Antwoord 22

Er lijkt altijd enige verwarring te bestaan ​​over het gebruik van de HTTP POST versus de HTTP PUT-methode voor REST-services. De meeste ontwikkelaars zullen proberen CRUD-bewerkingen rechtstreeks aan HTTP-methoden te koppelen. Ik zal betogen dat dit niet correct is en dat men de CRUD-concepten niet zomaar kan associëren met de HTTP-methoden. Dat is:

Create => HTTP PUT
Retrieve => HTTP GET
Update => HTTP POST
Delete => HTTP DELETE

Het is waar dat de R(etrieve) en D(elete) van de CRUD-bewerkingen rechtstreeks kunnen worden toegewezen aan respectievelijk de HTTP-methoden GET en DELETE. De verwarring zit hem echter in de bewerkingen C(reate) en U(update). In sommige gevallen kan men de PUT gebruiken voor een creatie, terwijl in andere gevallen een POST vereist zal zijn. De dubbelzinnigheid ligt in de definitie van een HTTP PUT-methode versus een HTTP POST-methode.

Volgens de HTTP 1.1-specificaties moeten de GET-, HEAD-, DELETE- en PUT-methoden idempotent zijn en is de POST-methode niet idempotent. Dat wil zeggen dat een bewerking idempotent is als deze een of meerdere keren op een resource kan worden uitgevoerd en altijd dezelfde status van die resource teruggeeft. Terwijl een niet-idempotente bewerking een gewijzigde staat van de bron van het ene verzoek naar het andere kan retourneren. Daarom is er bij een niet-idempotente bewerking geen garantie dat men dezelfde staat van een hulpbron zal ontvangen.

Op basis van de bovenstaande idempotent-definitie is mijn mening over het gebruik van de HTTP PUT-methode versus het gebruik van de HTTP POST-methode voor REST-services:
Gebruik de HTTP PUT-methode wanneer:

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 beide gevallen kunnen deze bewerkingen meerdere keren worden uitgevoerd met hetzelfde resultaat. Dat wil zeggen dat de resource niet wordt gewijzigd door de bewerking meer dan één keer aan te vragen. Een echte idempotente operatie dus.
Gebruik de HTTP POST-methode wanneer:

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.

Conclusie

Correleer en wijs CRUD-bewerkingen niet rechtstreeks aan HTTP-methoden voor REST-services. Het gebruik van een HTTP PUT-methode versus een HTTP POST-methode moet gebaseerd zijn op het idempotente aspect van die bewerking. Dat wil zeggen, als de bewerking idempotent is, gebruik dan de HTTP PUT-methode. Als de bewerking niet idempotent is, gebruik dan de HTTP POST-methode.

---

Antwoord 23

de oorspronkelijke server kan de bron maken met die URI

Dus je gebruikt POST en waarschijnlijk, maar niet noodzakelijke PUT voor het maken van bronnen. Je hoeft niet beide te steunen. Voor mij is POST perfect genoeg. Het is dus een ontwerpbeslissing.

Zoals uw citaat al zei, gebruikt u PUT voor het maken van er is geen resource toegewezen aan een IRI en u wilt toch een resource maken. PUT /users/123/password vervangt bijvoorbeeld meestal het oude wachtwoord door een nieuw wachtwoord, maar u kunt het gebruiken om een ​​wachtwoord aan te maken als het nog niet bestaat (bijvoorbeeld door pas geregistreerde gebruikers of door verbannen gebruikers te herstellen).

---

Antwoord 24

Ik ga landen met het volgende:

PUT verwijst naar een bron, geïdentificeerd door de URI. In dit geval bent u het aan het bijwerken. Het is het deel van de drie werkwoorden dat verwijst naar hulpbronnen — delete en krijg de andere twee.

POST is in feite een bericht in vrije vorm, waarvan de betekenis ‘buiten de band’ is gedefinieerd. Als het bericht kan worden geïnterpreteerd als het toevoegen van een bron aan een directory, zou dat goed zijn, maar in principe moet je het bericht dat je verzendt (posten) begrijpen om te weten wat er met de bron zal gebeuren.

---

Omdat PUT en GET en DELETE naar een resource verwijzen, zijn ze ook per definitie idempotent.

POST kan de andere drie functies uitvoeren, maar dan gaat de semantiek van het verzoek verloren voor de tussenpersonen zoals caches en proxy’s. Dit geldt ook voor het bieden van beveiliging op de bron, aangezien de URI van een bericht niet noodzakelijk de bron aangeeft waarop het van toepassing is (het kan wel).

Een PUT hoeft geen create te zijn; de service kan een fout maken als de bron nog niet is gemaakt, maar deze anders bijwerken. Of omgekeerd — het kan de bron maken, maar geen updates toestaan. Het enige dat nodig is voor PUT is dat het verwijst naar een specifieke bron, en de payload is de representatie van die bron. Een succesvolle PUT betekent (behoudens interferentie) dat een GET dezelfde bron zou ophalen.

---

Bewerken: nog iets — een PUT kan creëren, maar als dat het geval is, moet de ID een natuurlijke ID zijn — oftewel een e-mailadres. Op die manier is de tweede put een update van de eerste als je twee keer PUT doet. Dit maakt het idempotent.

Als de ID wordt gegenereerd (bijvoorbeeld een nieuwe werknemers-ID), dan zou de tweede PUT met dezelfde URL een nieuw record creëren, wat in strijd is met de idempotent-regel. In dit geval zou het werkwoord POST zijn en zou de boodschap (niet resource) zijn om een ​​resource te maken met behulp van de waarden die in dit bericht zijn gedefinieerd.

---

Antwoord 25

De semantiek wordt verondersteld anders te zijn, in die zin dat “PUT”, zoals “GET” idempotent zou moeten zijn — wat betekent dat je hetzelfde exacte PUT-verzoek meerdere keren kunt doen en het resultaat zal zijn alsof je het maar één keer hebt uitgevoerd .

Ik zal de conventies beschrijven die volgens mij het meest worden gebruikt en het nuttigst zijn:

Als je een bron op een bepaalde URL PUT, gebeurt het dat het op die URL moet worden opgeslagen, of iets in die richting.

Wanneer u POST naar een bron op een bepaalde URL, plaatst u vaak een gerelateerd stuk informatie op die URL. Dit houdt in dat de bron op de URL al bestaat.

Als u bijvoorbeeld een nieuwe stream wilt maken, kunt u deze op een URL PUTeren. Maar als je een bericht naar een bestaande stream wilt POST, POST je naar de URL.

Wat betreft het wijzigen van de eigenschappen van de stream, je kunt dat doen met PUT of POST. Gebruik in principe alleen “PUT” als de bewerking idempotent is – gebruik anders POST.

Houd er echter rekening mee dat niet alle moderne browsers andere HTTP-werkwoorden dan GET of POST ondersteunen.

---

Antwoord 26

Meestal gebruik je ze als volgt:

• POST een bron in een verzameling
• PUT een bron geïdentificeerd door collection/:id

Bijvoorbeeld:

• POST /items
• PUT /items/1234

In beide gevallen bevat de hoofdtekst van de aanvraag de gegevens voor de bron die moet worden gemaakt of bijgewerkt. Het zou uit de routenamen duidelijk moeten zijn dat POST niet idempotent is (als je het 3 keer noemt, worden er 3 objecten gemaakt), maar PUT is idempotent (als je het 3 keer noemt is het resultaat hetzelfde). PUT wordt vaak gebruikt voor “upsert”-bewerking (maken of bijwerken), maar u kunt altijd een 404-fout retourneren als u deze alleen wilt gebruiken om te wijzigen.

Merk op dat POST een nieuw element in de verzameling “creëert”, en PUT een element “vervangt” op een bepaalde URL, maar het is heel gebruikelijk om PUT te gebruiken voor gedeeltelijke wijzigingen, dat wil zeggen, gebruik het alleen om bij te werken bestaande bronnen en pas alleen de opgenomen velden in de body aan (waarbij de andere velden worden genegeerd). Dit is technisch onjuist, als je REST-purist wilt zijn, moet PUT de hele bron vervangen en moet je PATCH gebruiken voor de gedeeltelijke update. Persoonlijk maakt het me niet zoveel uit, zolang het gedrag duidelijk en consistent is voor al je API-eindpunten.

Vergeet niet dat REST een reeks conventies en richtlijnen is om uw API eenvoudig te houden. Als je een ingewikkelde work-around krijgt om alleen maar het vakje “RESTfull” aan te vinken, schiet je doel voorbij 😉

---

Antwoord 27

Hier is een eenvoudige regel:

PUT naar een URL moet worden gebruikt om de bron bij te werken of te maken die zich op die URL kan bevinden.

POST naar een URL moet worden gebruikt om een ​​bron bij te werken of te maken die zich op een andere (“ondergeschikte”) URL bevindt, of die niet via HTTP kan worden gelokaliseerd.

---

Antwoord 28

Als u bekend bent met databasebewerkingen,
er zijn

1. Selecteer
2. Invoegen
3. Bijwerken
4. Verwijderen
5. Samenvoegen (bijwerken indien reeds aanwezig, anders invoegen)

Ik gebruik PUT voor het samenvoegen en bijwerken van bewerkingen en gebruik POST voor invoegingen.

---

Antwoord 29

Hoewel er waarschijnlijk een agnostische manier is om deze te beschrijven, lijkt deze in strijd te zijn met verschillende verklaringen van antwoorden op websites.

Laten we hier heel duidelijk en direct zijn. Als u een .NET-ontwikkelaar bent die met Web API werkt, zijn de feiten (uit de Microsoft API-documentatie),
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.

Natuurlijk kunt u “POST” gebruiken om te updaten, maar volg gewoon de conventies die voor u zijn opgesteld met uw gegeven framework. In mijn geval is het .NET / Web API, dus PUT is voor UPDATE er is geen discussie.

Ik hoop dat dit alle Microsoft-ontwikkelaars helpt die alle opmerkingen met links naar Amazon en Sun/Java-websites lezen.

---

Antwoord 30

In de praktijk werkt POST goed voor het maken van bronnen. De URL van de nieuw gemaakte resource moet worden geretourneerd in de koptekst van het locatieantwoord. PUT moet worden gebruikt om een ​​bron volledig bij te werken. Begrijp alsjeblieft dat dit de best practices zijn bij het ontwerpen van een RESTful API. De HTTP-specificatie als zodanig beperkt het gebruik van PUT/POST niet met een paar beperkingen voor het maken/bijwerken van bronnen. Kijk eens op http://techoctave.com/c7/posts/71 -twitter-rest-api-dissected dat de best practices samenvat.