PUT

Metoda PUT zahteva, da se stanje ciljnega vira ustvari ali zamenja s stanjem, ki ga določa predstavitev, vsebovana v koristnem tovoru sporočila zahteve. Uspešno izveden postopek PUT določene predstavitve pomeni, da se bo pri naknadnem GET na istem ciljnem viru v odgovoru 200 (OK) poslala enakovredna predstavitev. Vendar ni nobenega zagotovila, da bo takšno spremembo stanja mogoče opazovati, saj lahko na ciljni vir vzporedno delujejo drugi uporabniški agenti ali pa ga izvorni strežnik dinamično obdela, preden prejme naknadni GET. Uspešen odziv pomeni le, da je bil namen uporabniškega agenta dosežen v času obdelave v izvornem strežniku.

Če ciljni vir nima trenutne predstavitve in jo PUT uspešno ustvari, potem izvorni strežnik MORA obvestiti uporabniškega agenta s pošiljanjem odgovora 201 (Created). Če ciljni vir ima trenutno predstavitev in je ta predstavitev uspešno spremenjena v skladu s stanjem priložene predstavitve, mora izvorni strežnik poslati odgovor 200 (OK) ali 204 (Brez vsebine), da bi sporočil uspešno dokončanje zahteve.

Izvorni strežnik PRAVILNO ignorira neprepoznana polja glave, prejeta v zahtevi PUT (tj, jih ne shrani kot del stanja vira).

Server izvora PRAVILNO preveri, ali je predstavitev PUT skladna z vsemi omejitvami, ki jih ima strežnik za ciljni vir in ki jih PUT ne more ali ne bo spremenil. To je še posebej pomembno, kadar izvorni strežnik uporablja notranje konfiguracijske informacije, povezane z URI, da bi določil vrednosti za metapodatke predstavitve v odgovorih GET. Kadar predstavitev PUT ni skladna s ciljnim virom, izvorni strežnik PRAVILNO poskrbi, da sta skladna, tako da preoblikuje predstavitev ali spremeni konfiguracijo vira, ali pa se odzove z ustreznim sporočilom o napaki, ki vsebuje dovolj informacij, da pojasni, zakaj predstavitev ni primerna. Predlagani sta kodi stanja 409 (Conflict) ali 415 (Unsupported Media Type), pri čemer je slednja specifična za omejitve vrednosti Content-Type.

Na primer, če je ciljni vir konfiguriran tako, da ima vedno Content-Type "text/html", predstavitev, ki se vnaša, pa ima Content-Type "image/jpeg", bi moral izvorni strežnik storiti eno od naslednjega:

• a. ponovno konfigurira ciljni vir, da odraža novo vrsto medija;
• b. pretvori predstavitev PUT v obliko, ki je skladna z obliko vira, preden jo shrani kot novo stanje vira; ali,
• c. zavrne zahtevo z odgovorom 415 (nepodprta vrsta medija), ki navaja, da je ciljni vir omejen na "besedilo/html", in morda vključi povezavo do drugega vira, ki bi bil primeren cilj za novo predstavitev.

HTTP ne določa natančno, kako metoda PUT vpliva na stanje izvornega strežnika, razen tega, kar je mogoče izraziti z namenom zahteve uporabniškega agenta in semantiko odgovora izvornega strežnika. Ne opredeljuje, kaj je lahko vir v katerem koli pomenu te besede, razen vmesnika, ki ga zagotavlja protokol HTTP. Ne opredeljuje, kako je stanje vira "shranjeno" in kako se lahko takšno shranjevanje spremeni zaradi spremembe stanja vira ter kako izvorni strežnik prevede stanje vira v predstavitve. Na splošno so vse izvedbene podrobnosti za vmesnikom vira namenoma skrite s strani strežnika.

Srver izvora NE MORE poslati potrditvenega naslovnega polja (razdelek 7.2), kot je polje ETag ali Last-Modified, v uspešnem odgovoru na zahtevo PUT, razen če so bili podatki predstavitve zahteve shranjeni brez kakršne koli pretvorbe telesa (tj. novi podatki predstavitve vira so enaki kot podatki predstavitve, prejeti v zahtevi PUT) in vrednost potrditvenega polja odraža novo predstavitev. Ta zahteva uporabniškemu agentu omogoča, da ve, kdaj je telo predstavitve, ki ga ima v spominu, zaradi PUT še vedno aktualno in ga zato ni treba ponovno pridobiti iz izvornega strežnika, ter da se lahko novi validator(-i), prejeti v odgovoru, uporabi za prihodnje pogojne zahteve, da se prepreči naključno prepisovanje (oddelek 5.2).

Poslednjo razliko med metodama POST in PUT poudarja drugačen namen za priloženo predstavitev. Ciljni vir v zahtevi POST je namenjen obravnavi priložene predstavitve v skladu z lastno semantiko vira, medtem ko je priložena predstavitev v zahtevi PUT opredeljena kot zamenjava stanja ciljnega vira. Zato je namen zahteve PUT idempotenten in viden posrednikom, čeprav natančen učinek pozna le izvorni strežnik.

Pravilna razlaga zahteve PUT predpostavlja, da uporabniški agent ve, kateri ciljni vir je želen. Storitev, ki v imenu odjemalca izbere ustrezen URI, potem ko prejme zahtevo za spremembo stanja, JE POTREBNO izvajati z uporabo metode POST in ne PUT. Če izvorni strežnik ne bo izvedel zahtevane spremembe stanja PUT v ciljnem viru in namesto tega želi, da se uporabi za drug vir, na primer, ko je bil vir prestavljen na drug URI, potem mora izvorni strežnik poslati ustrezen odgovor 3xx (preusmeritev); uporabniški agent se lahko nato sam odloči, ali bo zahtevo preusmeril ali ne.

Zahtevek PUT, uporabljen za ciljni vir, ima lahko stranske učinke na druge vire. Na primer, članek ima lahko URI za identifikacijo "trenutne različice" (vir), ki je ločen od URI, ki identificirajo vsako posamezno različico (različni viri, ki so v nekem trenutku imeli isto stanje kot vir trenutne različice). Uspešna zahteva PUT na URI "trenutne različice" lahko zato poleg spremembe stanja ciljnega vira ustvari nov vir različice in povzroči tudi dodajanje povezav med povezanimi viri.

Server izvora, ki omogoča PUT na danem ciljnem viru, MORA poslati odgovor 400 (Bad Request) na zahtevo PUT, ki vsebuje naslovno polje Content-Range (oddelek 4.2 [RFC7233]), saj je tovor verjetno delna vsebina, ki je bila pomotoma oddana kot popolna predstavitev. Delne posodobitve vsebine so mogoče z usmerjanjem na ločeno določen vir s stanjem, ki prekriva del večjega vira, ali z uporabo druge metode, ki je posebej opredeljena za delne posodobitve (na primer metoda PATCH, opredeljena v [RFC5789]).

Odgovorov na metodo PUT ni mogoče shraniti v predpomnilnik. Če uspešna zahteva PUT poteka skozi predpomnilnik, ki ima enega ali več shranjenih odgovorov za dejanski URI zahteve, bodo ti shranjeni odgovori razveljavljeni (glejte razdelek 4.4 [RFC7234]).