Дополнительные методы запросов

Метод PATCH

Метод PATCH подобен PUT, за исключением того, что объект содержит список отличий между оригинальной версией ресурса, идентифицированного Request-URI, и желательной версией ресурса после операции PATCH. Список отличий записывается в формате, определенном типом среды объекта (например, application/diff), и должен включать достаточную информацию, чтобы позволить серверу выполнить изменения по преобразованию ресурса из исходной версии в заказанную.

Если запрос проходит через кэш и Request-URI идентифицирует объект в кэше, этот объект должен быть удален из кэша. Отклики для этого метода не кэшируются.

Реальный метод определения того, как разместится скорректированный ресурс и что случится с его предшественником, определяется исключительно исходным сервером. Если оригинальная версия ресурса, который предполагается скорректировать, включает в себя поле заголовка Content-Version, объект запроса должен включать поле заголовка Derived-From, соответствующее значению оригинального поля заголовка Content-Version. Приложениям рекомендуется использовать эти поля для работы с версиями с целью разрешения соответствующих конфликтов. Запросы PATCH должны подчиняться требованиям к передаче сообщений. Кэши, которые реализуют PATCH, должны объявить кэшированные отклики недействительными.

Метод LINK

Метод LINK устанавливает одну или более связей между ресурсами, идентифицированными Request-URI, и другими существующими ресурсами. Отличие между LINK и другими методами, допускающими установление связей между ресурсами, заключается в том, что метод LINK не позволяет послать в запросе любое тело сообщения и не вызывает непосредственно создания новых ресурсов. Если запрос проходит через кэш и Request-URI идентифицирует кэшированный объект, этот объект должен быть удален из кэша. Отклики на этот метод не кэшируются. Кэши, которые реализуют LINK, должны объявить кэшированные отклики непригодными.

Определения дополнительных полей заголовка

Поле Alternates

Поле заголовка отклика Alternates было предложено в качестве средства исходного сервера для информирования клиента о других доступных представлениях запрошенного ресурса. При этом выдается информация об их специфических атрибутах, и все это образует более надежное основание агенту пользователя для выбора представления, которое лучше соответствует желаниям пользователя. Поле заголовка Alternates является ортогональным по отношению к полю заголовка Vary, но вместе с тем они могут сосуществовать в сообщении без последствий для интерпретации отклика или доступных представлений. Ожидается, что поле Alternates предоставит заметное улучшение по сравнению с согласованием под управлением сервера, предлагаемым полем Vary для ресурсов, которые варьируются в общих пределах подобно типу и языку.

Поле Content-Version

Поле заголовка объекта Content-Version определяет метку версии, ассоциированную с отображением объекта. Вместе с полем Derived-From, это позволяет группе людей вести разработку в интерактивном режиме.

Content-Version = "Content-Version" ":" quotedstring.

Примеры использования поля Content-Version:

Content-Version: "1.3.1"
Content-Version: "Fred 1895011511:25:39"
Content-Version: "2.6b4omega8"

Поле Derived-From

Поле заголовка объекта Derived-From может использоваться для индикации метки версии ресурса, из которого был извлечен объект до модификации, выполненной отправителем. Это поле применяется для того, чтобы помочь управлять процессом эволюции ресурса, в частности, когда изменения выполняются параллельно многими субъектами.

Derived-From = "Derived-From" ":" quotedstring.

Пример использования поля:

Derived-From: "1.1.1".

Поле Derived-From необходимо для запросов PUT и PATCH, если посланный объект был перед этим извлечен из того же URI и заголовок Content-Version был включен в объект, когда он последний раз извлекался.

Поле Link

Поле заголовка объекта Link предоставляет средства для описания взаимоотношений между ресурсами. Объект может включать много значений поля Link. Связи на уровне метаинформации обычно указывают на отношения типа структуры иерархии и пути прохода. Поле Link семантически эквивалентно элементу в HTML [7.5].

Link = "Link" ":"#("<" URI ">" *(";" linkparam)
linkparam = (("rel" "=" relationship )
| ("rev" "=" relationship)
| ( 'title" "=" quotedstring )
| ( "anchor" "=" <"> URI <"> )
| (linkextension ))
linkextension = token ["=" (token | quotedstring )]
Relationship = sgmlname
| ( <"> sgmlname *( SP sgmlname) <"> )
sgmlname = ALPHA *( ALPHA | DIGIT | "." | "")

Запись значений отношения не зависит от использования строчных или прописных букв и может быть расширена в рамках синтаксиса имен sgml. Параметр заголовка может быть применен для пометки места назначения связи, такой, какая используется при идентификации в рамках меню для пользователя. Параметр типа якорь может иллюстрировать индикацию источника якоря, отличного от всего текущего ресурса, такого, как фрагмент данного ресурса. Примеры использования:

Link: ; rel="Previous"
Link: ; rev="Made"; title="Tim BernersLee"

Первый пример указывает, что глава 2 предшествует данному ресурсу с точки зрения логического прохода. Второй демонстрирует, что лицо, ответственное за данный ресурс, имеет приведенный адрес электронной почты.

Система проксисерверов приобрела всемирный характер и главная ее задача — минимизация транзитного трафика. Но часто может возникать ситуация, когда требующийся объект содержится в проки­сервере, размещенном неподалеку, но не вдоль маршрута к исходному серверу. В этом случае запрос будет послан исходному серверу, что может создать дополнительную загрузку в большом числе внешних каналов. Представляется целесообразным обмен данными между прокси о заголовках объектов, хранящихся там. Такая информация может существенно снизить транзитный трафик. Можно попытаться изменить протокол так, чтобы объекты размещались в тех прокси, для которых среднеквадратичные расстояние до совокупности клиентов, запрашивавших этот ресурс, было минимальным.

Вопросы:

1 Что такое HTTP протокол?
2 Для чего используется HTTP протокол
3 Характеристики HTTP протокола
4 HTTP протокол работает по принципу клиент-сервер
5 История HTTP: стандарты HTTP протокола
6 Клиенты HTTP протокола
7 Серверы HTTP протокола
8 Требования HTTP протокола
9 Структура HTTP протокола
10 Терминология HTTP протокола
11 Параметры HTTP протокола
12 Как происходит общение по протоколу HTTP: HTTP сообщение, HTTP запрос и HTTP ответ
13 Методы в HTTP протоколе
14 Как происходит соединение по HTTP протоколу
15 Обсуждение содержимого в HTTP протоколе
16 Коды состояния в HTTP протоколе
17 Поля заголовка HTTP сообщения
18 Кэширование HTTP протокола
19 Безопасность HTTP протокола