PUT proti POST v REST

V skladu s specifikacijo HTTP/1.1:

Metoda POST se uporablja za zahtevo, da izvorni strežnik sprejme entiteto, ki je priložena zahtevi, kot novo podrejeno enoto vira, identificiranega z Request-URI v Request-Line.

Z drugimi besedami, POST se uporablja za ustvarjanje.

Metoda PUT zahteva, da se priložena entiteta shrani pod navedenim Request-URI. Če se Request-URI nanaša na že obstoječi vir, je treba priloženo entiteto obravnavati kot spremenjeno različico tiste, ki se nahaja v izvornem strežniku. Če Request-URI ne kaže na obstoječe sredstvo in lahko ta URI uporabniški agent, ki zahteva, določi kot novo sredstvo, lahko izvorni strežnik ustvari sredstvo s tem URI."

To pomeni, da se PUT uporablja za ustvarjanje ali posodabljanje.

Katero možnost je torej treba uporabiti za ustvarjanje vira? Ali je treba podpirati oboje?

Rešitev

Vse skupaj:

Za ustvarjanje se lahko uporabljata tako PUT kot POST.

Vprašati se morate "na kaj izvajate akcijo?", da bi razlikovali, kaj morate uporabiti. Recimo, da oblikujete API za postavljanje vprašanj. Če želite uporabiti POST, bi to storili za seznam vprašanj. Če želite uporabiti PUT, bi to storili za določeno vprašanje.

Veliko je, da lahko uporabite oba načina, katerega naj torej uporabim v svoji zasnovi RESTful:

Ni treba, da podpirate tako PUT kot POST.

Katero boste uporabili, je odvisno od vas. Vendar ne pozabite uporabiti pravega glede na to, na kateri objekt se sklicujete v zahtevi.

Nekaj premislekov:

  • Ali objekte URL, ki jih ustvarjate, poimenujete izrecno ali to prepustite strežniku? Če jih poimenujete, uporabite PUT. Če dovolite strežniku, da se odloči, uporabite POST.
  • Funkcija PUT je idempotentna, zato če objekt dvakrat vpišete, to nima učinka. To je lepa lastnost, zato bi uporabil PUT, kadar je to mogoče.
  • S PUT lahko posodobite ali ustvarite vir z istim naslovom URL objekta
  • S POST lahko hkrati prejmete dve zahtevi, ki spreminjata naslov URL, pri čemer lahko posodobita različne dele objekta.

Naprimer:

Naslednje sem napisal kot del drugega odgovora na SO v zvezi s tem:

POST:

Uporablja se za spreminjanje in posodabljanje vira

POST /questions/ HTTP/1.1 Gostitelj: www.example.com/

Upoštevajte, da je naslednje napaka:

POST /questions/ HTTP/1.1 Gostitelj: www.example.com/

Če naslov URL še ni ustvarjen, lahko za njegovo ustvarjanje ne smete uporabiti metode POST pri določanju imena. To bi moralo povzroči napako 'resource not found' ker ne obstaja še ni. Vstaviti morate vir na strežniku.

Lahko pa naredite nekaj takega to, da ustvarite vir z uporabo POST:

POST /questions HTTP/1.1 Gostitelj: www.example.com/

Upoštevajte, da je v tem primeru vir ime ni določeno, novi predmeti URL pot bo vrnjena.

PUT:

Uporablja se za ustvarjanje vira ali ga prepišete. Medtem ko določate virov nov URL.

Za nov vir:

PUT /questions/ HTTP/1.1 Gostitelj: www.example.com/

Za prepis obstoječega vira:

PUT /questions/ HTTP/1.1 Gostitelj: www.example.com/

Komentarji (41)

Za ustvarjanje uporabite POST, za posodabljanje pa PUT. Tako to počne Ruby on Rails.

PUT    /items/1      #=> update
POST   /items        #=> create
Komentarji (8)

REST je koncept na zelo visoki ravni. Pravzaprav sploh ne omenja protokola HTTP!

Če dvomite, kako izvajati REST v HTTP, si lahko vedno ogledate specifikacijo Atom Publication Protocol (AtomPub). AtomPub je standard za pisanje spletnih storitev REST s protokolom HTTP, ki so ga razvili številni strokovnjaki s področja HTTP in REST, pri čemer je sodeloval tudi Roy Fielding, izumitelj protokola REST in (so)izumitelj protokola HTTP.

Pravzaprav boste lahko AtomPub uporabljali neposredno. Čeprav izhaja iz skupnosti blogerjev, nikakor ni omejen na bloge: je splošen protokol za interakcijo REST s poljubnimi (gnezdenimi) zbirkami poljubnih virov prek protokola HTTP. Če lahko svojo aplikacijo predstavite kot vgnezdeno zbirko virov, lahko uporabite AtomPub in ne skrbite, ali uporabiti PUT ali POST, katere kode stanja HTTP vrniti in vse druge podrobnosti.

To je tisto, kar ima AtomPub povedati o ustvarjanju virov (razdelek 9.2):

Za dodajanje članov v zbirko odjemalci pošljejo zahtevke POST na URI zbirke.

Komentarji (9)