PUT

Med PUT-metoden begärs att målresursens tillstånd skapas eller ersätts med det tillstånd som definieras av den representation som bifogas nyttolasten i begäran. En lyckad PUT av en given representation skulle innebära att en efterföljande GET på samma målresurs kommer att resultera i att en motsvarande representation skickas i ett 200 (OK) svar. Det finns dock ingen garanti för att en sådan tillståndsändring kommer att kunna observeras, eftersom målresursen kan hanteras av andra användaragenter parallellt eller kan vara föremål för dynamisk behandling av ursprungsservern, innan någon efterföljande GET tas emot. Ett lyckat svar innebär endast att användaragentens avsikt uppnåddes vid tidpunkten för dess behandling av ursprungsservern.

Om målresursen inte har en aktuell representation och PUT lyckas skapa en, MÅSTE ursprungsservern informera användaragenten genom att skicka ett 201-svar (Created). Om målresursen har en aktuell representation och den representationen har modifierats i enlighet med tillståndet för den bifogade representationen, MÅSTE ursprungsservern skicka antingen ett 200 (OK) eller ett 204 (Inget innehåll) svar för att ange att begäran har slutförts.

En ursprungsserver SKA ignorera okända rubrikfält som tas emot i en PUT-begäran (dvs, spara dem inte som en del av resurstillståndet).

En ursprungsserver BÖR verifiera att PUT-representationen överensstämmer med eventuella begränsningar som servern har för målresursen och som inte kan eller kommer att ändras av PUT. Detta är särskilt viktigt när ursprungsservern använder intern konfigurationsinformation relaterad till URI för att ange värdena för representationsmetadata på GET-svar. När en PUT-representation inte överensstämmer med målresursen BÖR ursprungsservern antingen se till att de överensstämmer, genom att omvandla representationen eller ändra resurskonfigurationen, eller svara med ett lämpligt felmeddelande som innehåller tillräcklig information för att förklara varför representationen är olämplig. Statuskoderna 409 (Konflikt) eller 415 (Medietyp som inte stöds) föreslås, där den senare är specifik för begränsningar av innehållstypvärden.

Om målresursen till exempel är konfigurerad att alltid ha en innehållstyp av typen "text/html" och den representation som PUT har en innehållstyp av typen "image/jpeg", bör ursprungsservern göra något av följande:

• a. Omkonfigurera målresursen så att den återspeglar den nya medietypen;
• b. omvandla PUT-representationen till ett format som överensstämmer med resursens innan den sparas som det nya resurstillståndet; eller,
• c. avvisa begäran med ett 415-svar (Unsupported Media Type) som anger att målresursen är begränsad till "text/html", eventuellt med en länk till en annan resurs som skulle vara ett lämpligt mål för den nya representationen.

HTTP definierar inte exakt hur en PUT-metod påverkar tillståndet för en ursprungsserver utöver det som kan uttryckas genom avsikten med användaragentens begäran och semantiken i ursprungsserverns svar. Den definierar inte vad en resurs kan vara, i någon mening av det ordet, utöver det gränssnitt som tillhandahålls via HTTP. Den definierar inte hur resursstatus "lagras", inte heller hur sådan lagring kan förändras som ett resultat av en förändring i resursstatus, eller hur ursprungsservern översätter resursstatus till representationer. Generellt sett är alla implementeringsdetaljer bakom resursgränssnittet avsiktligt dolda av servern.

En ursprungsserver får INTE skicka ett validatorhuvudfält (avsnitt 7.2), t.ex. ett ETag- eller Last-Modified-fält, i ett framgångsrikt svar på PUT om inte förfrågningens representationsdata sparades utan någon transformation av kroppen (dvs. resursens nya representationsdata är identiska med de representationsdata som mottas i PUT-förfrågan) och validatorfältvärdet återspeglar den nya representationen. Detta krav gör att en användaragent kan veta när den representationskropp som den har i minnet förblir aktuell som ett resultat av PUT, och därmed inte behöver hämtas igen från ursprungsservern, och att de nya validatorer som tas emot i svaret kan användas för framtida villkorade förfrågningar för att förhindra oavsiktliga överskrivningar (avsnitt 5.2).

Den grundläggande skillnaden mellan metoderna POST och PUT belyses av de olika avsikterna för den bifogade representationen. Målresursen i en POST-begäran är avsedd att hantera den bifogade representationen enligt resursens egen semantik, medan den bifogade representationen i en PUT-begäran definieras som en ersättning av målresursens tillstånd. Därför är avsikten med PUT idempotent och synlig för mellanhänder, även om den exakta effekten endast är känd av ursprungsservern.

En korrekt tolkning av en PUT-begäran förutsätter att användaragenten vet vilken målresurs som önskas. En tjänst som väljer en korrekt URI för klientens räkning, efter att ha mottagit en tillståndsändrande begäran, BÖR implementeras med POST-metoden i stället för PUT. Om ursprungsservern inte kommer att göra den begärda PUT-tillståndsändringen för målresursen och istället vill att den ska tillämpas på en annan resurs, till exempel när resursen har flyttats till en annan URI, MÅSTE ursprungsservern skicka ett lämpligt 3xx-svar (omdirigering); användaragenten KAN sedan fatta sitt eget beslut om huruvida begäran ska omdirigeras eller inte.

En PUT-förfrågan som tillämpas på målresursen kan ha bieffekter på andra resurser. En artikel kan till exempel ha en URI för att identifiera "den aktuella versionen" (en resurs) som är skild från de URI:er som identifierar varje enskild version (olika resurser som vid en tidpunkt delade samma tillstånd som resursen för den aktuella versionen). En lyckad PUT-begäran på "den aktuella versionen" URI kan därför skapa en ny version resurs förutom att ändra tillståndet för målresursen, och kan också orsaka länkar att läggas till mellan de relaterade resurser.

En ursprungsserver som tillåter PUT på en viss målresurs MÅSTE skicka en 400 (Bad Request) svar på en PUT-begäran som innehåller en Content-Range rubrikfält (avsnitt 4.2 i [RFC7233]), eftersom nyttolasten sannolikt är delvis innehåll som felaktigt har PUT som en fullständig representation. Partiella innehållsuppdateringar är möjliga genom att rikta in sig på en separat identifierad resurs med tillstånd som överlappar en del av den större resursen, eller genom att använda en annan metod som har definierats specifikt för partiella uppdateringar (till exempel PATCH-metoden som definieras i [RFC5789]).

Svar på PUT-metoden är inte cachningsbara. Om en lyckad PUT-begäran passerar genom en cache som har ett eller flera lagrade svar för den effektiva begäran URI, kommer dessa lagrade svar att ogiltigförklaras (se avsnitt 4.4 i [RFC7234]).