PUT

Методът PUT изисква състоянието на целевия ресурс да бъде създадено или заменено със състоянието, определено от представянето, приложено в полезния товар на съобщението за заявка. Успешното PUT на дадено представяне предполага, че последващо GET на същия целеви ресурс ще доведе до изпращане на еквивалентно представяне в отговор 200 (OK). Въпреки това няма гаранция, че подобна промяна в състоянието ще бъде наблюдавана, тъй като целевият ресурс може да бъде обработван паралелно от други потребителски агенти или да бъде обект на динамична обработка от сървъра на произхода, преди да бъде получено каквото и да е последващо GET. Успешният отговор означава само, че намерението на потребителския агент е било постигнато в момента на обработката му от сървъра на произхода.

Ако целевият ресурс няма текущо представяне и PUT успешно създаде такова, тогава сървърът на произхода ТРЯБВА да информира потребителския агент, като изпрати отговор 201 (Created). Ако целевият ресурс има текущо представяне и това представяне е успешно модифицирано в съответствие със състоянието на приложеното представяне, тогава сървърът на произхода ТРЯБВА да изпрати отговор 200 (OK) или 204 (Няма съдържание), за да посочи успешното завършване на заявката.

Сървърът на произхода ТРЯБВА да игнорира неразпознати заглавни полета, получени в заявка PUT (т.е, не ги запазва като част от състоянието на ресурса).

Сървърът на произхода ТРЯБВА да провери дали представянето на PUT е съвместимо с всички ограничения, които сървърът има за целевия ресурс и които не могат или няма да бъдат променени от PUT. Това е особено важно, когато сървърът на произхода използва вътрешна конфигурационна информация, свързана с URI, за да зададе стойности за метаданните на представянето в отговорите GET. Когато представянето на PUT е несъвместимо с целевия ресурс, сървърът на произхода ТРЯБВА или да ги приведе в съответствие, като трансформира представянето или промени конфигурацията на ресурса, или да отговори с подходящо съобщение за грешка, съдържащо достатъчно информация, за да обясни защо представянето е неподходящо. Предлагат се кодовете за състояние 409 (Conflict) или 415 (Unsupported Media Type), като последният е специфичен за ограниченията на стойностите на Content-Type.

Например, ако целевият ресурс е конфигуриран винаги да има Content-Type от "text/html", а представянето, което се въвежда, има Content-Type от "image/jpeg", сървърът на произхода трябва да направи едно от следните действия:

• a. да преконфигурира целевия ресурс, за да отрази новия медиен тип;
• b. да трансформира представянето PUT във формат, съответстващ на този на ресурса, преди да го запази като ново състояние на ресурса; или,
• c. да отхвърли заявката с 415 (Unsupported Media Type) отговор, посочващ, че целевият ресурс е ограничен до "text/html", може би включвайки връзка към друг ресурс, който би бил подходяща цел за новото представяне.

HTTP не дефинира точно как методът PUT влияе върху състоянието на сървъра на произход извън това, което може да бъде изразено чрез намерението на заявката на потребителския агент и семантиката на отговора на сървъра на произход. Той не определя какво може да бъде ресурс в какъвто и да е смисъл на тази дума, извън интерфейса, предоставен чрез HTTP. Той не определя как се "съхранява" състоянието на ресурса, нито как това съхранение може да се промени в резултат на промяна в състоянието на ресурса, нито как сървърът на произхода превръща състоянието на ресурса в репрезентации. Най-общо казано, всички детайли за изпълнение зад интерфейса на ресурса са умишлено скрити от сървъра.

Сървърът на произхода НЕ ТРЯБВА да изпраща поле от заглавието на валидатора (раздел 7.2), като например поле ETag или Last-Modified, в успешен отговор на PUT, освен ако данните за представяне на заявката не са били запазени без никакво преобразуване, приложено към тялото (т.е. новите данни за представяне на ресурса са идентични с данните за представяне, получени в заявката PUT) и стойността на полето на валидатора отразява новото представяне. Това изискване позволява на потребителския агент да знае кога тялото на представянето, което има в паметта си, остава актуално в резултат на PUT, като по този начин не се нуждае от повторно извличане от сървъра на произхода, и че новият(те) валидатор(и), получен(и) в отговора, може да се използва(т) за бъдещи условни заявки, за да се предотврати случайно презаписване (раздел 5.2).

Основната разлика между методите POST и PUT се подчертава от различното намерение за приложеното представяне. Целевият ресурс в заявка POST е предназначен да обработва затвореното представяне в съответствие със собствената семантика на ресурса, докато затвореното представяне в заявка PUT е определено като заместващо състоянието на целевия ресурс. Следователно намерението на PUT е идентично и видимо за посредниците, въпреки че точният ефект е известен само на сървъра на произхода.

Правилното тълкуване на заявка PUT предполага, че потребителският агент знае кой целеви ресурс се желае. Услуга, която избира подходящ URI от името на клиента, след като получи заявка за промяна на състоянието, ТРЯБВА да бъде реализирана чрез използване на метода POST, а не PUT. Ако сървърът на произхода няма да извърши исканата промяна на състоянието PUT към целевия ресурс и вместо това желае тя да бъде приложена към друг ресурс, например когато ресурсът е преместен към друг URI, тогава сървърът на произхода ТРЯБВА да изпрати подходящ отговор 3xx (Пренасочване); след това потребителският агент МОЖЕ да вземе собствено решение дали да пренасочи заявката.

Заявката PUT, приложена към целевия ресурс, може да има странични ефекти върху други ресурси. Например една статия може да има URI за идентифициране на "текущата версия" (ресурс), който е отделен от URI, идентифициращи всяка конкретна версия (различни ресурси, които в един момент са споделяли същото състояние като ресурса на текущата версия). Следователно успешна заявка за PUT върху URI на "текущата версия" може да създаде нов ресурс на версията в допълнение към промяната на състоянието на целевия ресурс и може също така да доведе до добавяне на връзки между свързаните ресурси.

Сървърът на произхода, който позволява PUT върху даден целеви ресурс, ТРЯБВА да изпрати отговор 400 (лоша заявка) на заявка за PUT, която съдържа поле от заглавието Content-Range (раздел 4.2 от [RFC7233]), тъй като полезният товар вероятно е частично съдържание, което погрешно е било въведено като пълно представяне. Частични актуализации на съдържанието са възможни чрез насочване към отделно идентифициран ресурс със състояние, което се припокрива с част от по-големия ресурс, или чрез използване на друг метод, който е специално дефиниран за частични актуализации (например методът PATCH, дефиниран в [RFC5789]).

Отговорите на метода PUT не могат да се кешират. Ако успешна заявка по метода PUT премине през кеш, който има един или повече съхранени отговори за ефективния URI на заявката, тези съхранени отговори ще бъдат анулирани (вж. раздел 4.4 на [RFC7234]).