PUT kontra POST i REST

Sammantaget:

Både PUT och POST kan användas för att skapa.

Du måste fråga dig "vad utför du åtgärden på?" för att avgöra vad du ska använda. Låt oss anta att du utformar ett API för att ställa frågor. Om du vill använda POST skulle du göra det på en lista med frågor. Om du vill använda PUT skulle du göra det för en viss fråga.

Båda kan användas, så vilken ska jag använda i min RESTful-design:

Du behöver inte ha stöd för både PUT och POST.

Vilket som används är upp till dig. Men kom ihåg att använda rätt beroende på vilket objekt du hänvisar till i begäran.

Några överväganden:

• Namnger du dina URL-objekt som du skapar uttryckligen eller låter du servern bestämma? Om du namnger dem använder du PUT. Om du låter servern bestämma använder du POST.
• PUT är idempotent, så om du PUTar ett objekt två gånger har det ingen effekt. Detta är en trevlig egenskap, så jag skulle använda PUT när det är möjligt.
• Du kan uppdatera eller skapa en resurs med PUT med samma objekt-URL.
• Med POST kan du ha två förfrågningar som kommer in samtidigt och gör ändringar i en URL, och de kan uppdatera olika delar av objektet.

Ett exempel:

Jag skrev följande som en del av ett annat svar på SO om detta:

POST:

Används för att ändra och uppdatera en resurs

POST /questions/ HTTP/1.1 Värd: www.example.com/

Observera att följande är ett fel:

POST /questions/ HTTP/1.1 Värd: www.example.com/

Om webbadressen ännu inte har skapats kan du bör du inte använda POST för att skapa den. när du anger namnet. Detta bör resultera i ett 'resource not found' fel. eftersom <new_question> inte finns. inte finns ännu. Du bör PUTA in <new_question>. resursen på servern först.

Du kan dock göra något liknande som så här för att skapa en resurs med POST:

POST /questions HTTP/1.1 Värd: www.example.com/

Observera att i detta fall är resursen namn inte anges, de nya objekten URL-sökvägen returneras till dig.

PUT:

Används för att skapa en resurs, eller skriva över den. Medan du anger resursens nya URL.

För en ny resurs:

PUT /questions/ HTTP/1.1 Värd: www.example.com/

För att skriva över en befintlig resurs:

PUT /questions/ HTTP/1.1 Värd: www.example.com/

Använd POST för att skapa och PUT för att uppdatera. Det är i alla fall så Ruby on Rails gör det.

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

REST är ett koncept på mycket hög nivå. Faktum är att det inte ens nämns HTTP överhuvudtaget!

Om du är osäker på hur man implementerar REST i HTTP kan du alltid ta en titt på [Atom Publication Protocol (AtomPub)][1] specifikationen. AtomPub är en standard för att skriva RESTful-webbtjänster med HTTP som utvecklades av många HTTP- och REST-koryféer, med viss input från Roy Fielding, REST:s uppfinnare och HTTP:s (med)uppfinnare själv.

Du kanske till och med kan använda AtomPub direkt. Det är ett generiskt protokoll för REST-interaktion med godtyckliga (inbäddade) samlingar av godtyckliga resurser via HTTP. Om du kan representera din applikation som en nästlad samling resurser kan du bara använda AtomPub och inte oroa dig för om du ska använda PUT eller POST, vilka HTTP-statuskoder som ska returneras och alla dessa detaljer.

Detta är vad AtomPub har att säga om skapande av resurser (avsnitt 9.2):

För att lägga till medlemmar i en samling skickar klienter POST-förfrågningar till samlingens URI.