PUT

Metoodika PUT taotleb, et sihtressursi olek loodaks või asendataks olekuga, mis on määratletud taotluse sõnumi kasuliku koormuse hulka lisatud esituses. Teatud esituse edukas PUT tähendab, et sama sihtressursi järgmine GET saadab vastuseks 200 (OK) samaväärse esituse. Siiski ei ole mingit garantiid, et selline olekumuutus on jälgitav, kuna sihtressursi suhtes võivad paralleelselt tegutseda teised kasutajaagendid või võib päritoluserver seda dünaamiliselt töödelda, enne kui järgmine GET saabub. Edukas vastus tähendab ainult seda, et kasutajaagendi kavatsus saavutati päritoluserveri poolt töötlemise ajal.

Kui sihtressursil ei ole praegust esindust ja PUT loob selle edukalt, siis PEAB päritoluserver sellest kasutajaagenti teavitama, saates vastuse 201 (Created). Kui sihtressursil on praegune esindus ja seda esindust on edukalt muudetud vastavalt lisatud esinduse olekule, siis PEAB päritoluserver saatma kas vastuse 200 (OK) või 204 (No Content), mis näitab taotluse edukat lõpetamist.

PUT-taotluses saadud tunnustamata päise väljad PEAB päritoluserver ignoreerima (st, ei salvesta neid ressursi oleku osana).

Algserver PEAB kontrollima, et PUT-esitus on kooskõlas kõigi piirangutega, mis serveril on sihtressursi suhtes, mida PUT ei saa või ei muudeta. See on eriti oluline, kui päritoluserver kasutab URIga seotud sisemist konfiguratsiooniteavet, et määrata GET-vastustes esitusmetaandmete väärtused. Kui PUT-esitus ei ole kooskõlas sihtressursiga, PEAB päritoluserver kas muutma need kooskõlas olevaks, muutes esituse või muutes ressursi konfiguratsiooni, või vastama asjakohase veateatega, mis sisaldavad piisavalt teavet, et selgitada, miks esitus ei sobi. Soovitatakse kasutada 409 (Conflict) või 415 (Unsupported Media Type) staatuskoode, kusjuures viimane on seotud Content-Type väärtuste piirangutega.

Kui näiteks sihtressurss on konfigureeritud nii, et selle Content-Type on alati "text/html" ja PUT esituse Content-Type on "image/jpeg", peaks päritoluserver tegema järgmist:

• a. sihtressursi ümberkonfigureerida, et see kajastaks uut meediatüüpi;
• b. muuta PUT-esitus enne selle salvestamist uue ressursi olekuna ressursi vorminguga kooskõlas olevaks;
• või,
• c. lükata taotlus tagasi vastusega 415 (Mittetoetav meediatüüp), mis näitab, et sihtressurss on piiratud "text/html"-ga, võib-olla koos lingiga teisele ressursile, mis oleks uue esituse jaoks sobiv sihtressurss.

HTTP ei määratle täpselt, kuidas PUT-meetod mõjutab päritoluserveri seisundit, välja arvatud see, mida saab väljendada kasutajaagendi taotluse kavatsusega ja päritoluserveri vastuse semantikaga. See ei määratle, mis võiks olla ressurss selle sõna mis tahes tähenduses, väljaspool HTTP kaudu pakutavat liidest. Selles ei määratleta, kuidas ressursi olek "salvestatakse", ega seda, kuidas selline salvestamine võib muutuda ressursi oleku muutumise tulemusena, ega seda, kuidas päritoluserver tõlgib ressursi oleku esitusviisidesse. Üldiselt on kõik ressursi liidese taga olevad rakendusdetailid serveri poolt tahtlikult varjatud.

Allikas server EI TOHI saata PUT-saatele eduka vastuse korral valideerivat päisevälja (punkt 7.2), näiteks ETag- või Last-Modified-välja, välja, välja arvatud juhul, kui taotluse esitusandmed salvestati ilma keha suhtes kohaldatud ümberkujundamiseta (st ressursi uued esitusandmed on identsed PUT-saates saadud esitusandmetega) ja valideeriva välja väärtus kajastab uut esitust. See nõue võimaldab kasutajaagendil teada saada, millal tema mälus olev esinduse keha jääb PUTi tulemusena ajakohaseks, mistõttu seda ei ole vaja päritoluserverist uuesti välja otsida, ning et vastuses saadud uut valideerijat (uusi valideerijaid) saab kasutada tulevaste tingimuslike taotluste puhul, et vältida juhuslikku ülekirjutamist (punkt 5.2).

POST- ja PUT-meetodite põhiline erinevus tuleb esile lisatud esinduse erineva kavatsuse tõttu. POST-taotluse sihtressursi eesmärk on käsitleda lisatud esitust vastavalt ressursi enda semantikale, samas kui PUT-taotluse lisatud esitus on määratletud kui sihtressursi oleku asendamine. Seega on PUT-päringu kavatsus idempotentne ja vahendajatele nähtav, kuigi täpne mõju on teada ainult päritoluserverile.

PUT-päringu õige tõlgendamine eeldab, et kasutajaagent teab, millist sihtressurssi soovitakse. Teenus, mis valib kliendi nimel õige URI pärast olekut muutva päringu saamist, PEAB olema rakendatud POST-meetodit kasutades, mitte PUT-meetodit. Kui lähteserver ei tee taotletud PUT-staatuse muutmist sihtressursile ja soovib selle asemel, et seda rakendataks teisele ressursile, näiteks kui ressurss on viidud teisele URI-le, siis PEAB lähteserver saatma asjakohase 3xx (Redirection) vastuse; kasutajaagent VÕIB seejärel ise otsustada, kas suunata taotlus ümber või mitte.

Kohtressursile rakendatud PUT-taotlusel võib olla kõrvalmõjusid teistele ressurssidele. Näiteks võib artiklil olla URI "praeguse versiooni" (ressurss) identifitseerimiseks, mis on eraldi URI-dest, mis identifitseerivad iga konkreetset versiooni (erinevad ressursid, mis mingil hetkel jagasid sama olekut kui praeguse versiooni ressurss). Edukas PUT päring "praeguse versiooni" URI-le võib seega lisaks sihtressursi oleku muutmisele luua uue versiooniressursi ja põhjustada ka seotud ressursside vaheliste linkide lisamist.

Algseserver, mis lubab PUT-i antud sihtressursil, PEAB saatma 400 (Bad Request) vastuse PUT päringule, mis sisaldab Content-Range päisevälja ([RFC7233] punkt 4.2), kuna kasuliku koormuse puhul on tõenäoliselt tegemist osalise sisuga, mis on ekslikult PUT-i teel esitatud täieliku esitusena. Osalise sisu uuendamine on võimalik, kui sihtmärgiks on eraldi määratletud ressurss, mille olek kattub suurema ressursi osaga, või kui kasutatakse muud meetodit, mis on spetsiaalselt määratletud osaliseks uuendamiseks (näiteks [RFC5789] määratletud PATCH-meetod).

PUT-meetodile antud vastused ei ole vahemällu paigutatavad. Kui edukas PUT päring läbib vahemälu, kus on üks või mitu salvestatud vastust tegeliku päringu URI jaoks, siis need salvestatud vastused tühistatakse (vt [RFC7234] punkt 4.4).