Enligt HTTP/1.1-specifikationen:
Metoden
POST
används för att begära att ursprungsservern ska acceptera den enhet som ingår i begäran som en ny underordnad till den resurs som identifieras avRequest-URI
iRequest-Line
.
Med andra ord används POST
för att skapa.
Metoden PUT
begär att den bifogade enheten lagras under den angivna Request-URI
. Om Request-URI
hänvisar till en redan existerande resurs, bör den bifogade enheten betraktas som en modifierad version av den som finns på ursprungsservern. Om Request-URI
inte pekar på en befintlig resurs, och den URI:n kan definieras som en ny resurs av den begärande användaragenten, kan ursprungsservern skapa resursen med den URI:n."
Det betyder att PUT
används för att skapa eller uppdatera.
Så vilken ska användas för att skapa en resurs? Eller måste man ha stöd för båda?
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:
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.