Сети и системы телекоммуникаций. Погонин В.А - 94 стр.

UptoLike

ВУЗ: 

ТГТУ | Тамбов

Составители: 

Рубрика: 

Ответы на этот метод не кэшируемы, если ответ не включает соответствующие поля заголов-
ка Cache-Control или Expires. Однако ответ с кодом состояния 303 (Смотреть другой, See Other)
может использоваться для перенаправления агента пользователя для загрузки кэшируемого ре-
сурса.
Запросы POST должны отвечать требованиям передачи сообщения.
9.4.9.6. PUT
Запросы с методом PUT, которые содержат объект, сохраняются под запрашиваемым URI
(Request-URI). Если Request-URI обращается к уже существующему ресурсу, включенный объект
следует рассматривать как модифицированную версию объекта, находящегося на первоначаль-
ном сервере. Если Request-URI не указывает на существующий ресурс, и может интерпретиро-
ваться агентом пользователя как новый ресурс для запросов, первоначальный сервер может соз-
дать ресурс с данным URI. Если новый ресурс создан, то первоначальный сервер должен сооб-
щить агенту пользователя об этом посредством ответа с кодом состояния 201 (Создан, Created).
Если существующий ресурс модифицирован, то для указания успешного завершения запроса сле-
дует послать ответ с кодом состояния либо 200 (OK), либо 204 (Нет содержимого, No Content). Ес-
ли ресурс не может быть создан или изменен для запрашиваемого URI (Request-URI), то следует
послать ответ, отражающий характер проблемы. Получатель объекта не должен игнорировать
заголовков Content-* (например Content-Range), которых не понимает или не реализует, а должен
в данном случае возвратить ответ с кодом состояния 501 (Не реализовано, Not Implemented).
Если запрос передается через кэш и запрашиваемый URI (Request-URI) идентифицирует один
или несколько кэшированных в настоящее время объектов, то вхождения в кэш этих объектов
должны обрабатываться как просроченные. Ответы на этот метод не кэшируемы.
Фундаментальное различие между запросами POST и PUT отражено в различном значении
запрашиваемого URI (Request-URI). URI в запросе POST идентифицирует ресурс, который обра-
батывает включенный объект. Этим ресурсом может быть процесс, принимающий данные, шлюз
к некоторому другому протоколу, или отдельный объект, который принимает аннотации (accepts
annotations). Напротив, URI в запросе PUT идентифицирует объект включенный в запрос – агент
пользователя назначает данный URI включенному ресурсу, а сервер не должен пытаться приме-
нить запрос к некоторому другому ресурсу. Если сервер желает применить запрос к другому URI,
он должен послать ответ с кодом 301 (Перемещен постоянно, Moved Permanently); агент пользова-
теля может затем принять собственное решение относительно переназначения запроса.
Один ресурс может быть идентифицирован несколькими различными URI. Например статья
может иметь URI идентифицирующий "текущую версию", который отличен от URI, идентифи-
цирующего каждую специфическую версию. В этом случае, запрос PUT на общий URI может от-
разиться на некоторых других URI, определенных первоначальным сервером.
HTTP/1.1 не определяет каким образом метод PUT воздействует на состояние первоначально-
го сервера.
Запросы PUT должны подчиняться требованиям передачи сообщений.
9.4.9.7. DELETE
Метод DELETE запрашивает первоначальный сервер об удалении ресурса, идентифицируе-
мого запрашиваемым URI (Request-URI). Этот метод может быть отменен человеческим вмеша-
тельством (или другими средствами) на первоначальном сервере. Клиенту нельзя гарантировать,
что операция была выполнена, даже если код состояния, возвращенный первоначальным серве-
ром указывает на то, что действие было завершено успешно. Однако, серверу не следует отвечать
об успешном выполнении, если во время формирования ответа он только собирается удалить ре-
сурс или переместить его в недоступное положение.
Успешному ответу следует иметь код состояния 200 (OK), если он включает объект, описы-
вающий состояние; иметь код состояния 202 (Принято, Accepted), если действие еще не было про-

Страницы