Методы RESTful API; ГОЛОВА И ОПЦИИ

Я пишу модуль RESTful API для приложения на PHP, и я немного запутался в глаголах HEADи OPTIONS.

• OPTIONS  Используется для получения доступных HTTP-глаголов для данного ресурса?
• HEAD Используется, чтобы определить, доступен ли данный ресурс?

Если бы кто-нибудь мог пояснить * эти глаголы, это было бы очень полезно.

_{* Уточнение касалось архитектур RESTful API, меняющих назначение HTTP-команд. С тех пор я пришел к выводу, что и то, HEADи другое неOPTIONS должно быть изменено, а вместо этого ведет себя предсказуемо, как и любое приложение HTTP. Ой, как мы растем за 2 года.}

Согласно: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

9.2 ОПЦИИ

Метод OPTIONS представляет собой запрос информации о вариантах связи, доступных в цепочке запроса / ответа, идентифицированной Request-URI. Этот метод позволяет клиенту определять параметры и / или требования, связанные с ресурсом, или возможности сервера, не подразумевая действие ресурса или инициируя извлечение ресурса.

Ответы на этот метод не кэшируются.

Если запрос OPTIONS включает тело объекта (на что указывает наличие Content-Length или Transfer-Encoding), то тип мультимедиа ДОЛЖЕН быть указан в поле Content-Type. Хотя эта спецификация не определяет использование такого тела, будущие расширения HTTP могут использовать тело OPTIONS для выполнения более подробных запросов на сервере. Сервер, который не поддерживает такое расширение, МОЖЕТ отказаться от тела запроса.

Если Request-URI - это звездочка («*»), запрос OPTIONS предназначен для применения к серверу в целом, а не к конкретному ресурсу. Поскольку параметры связи сервера обычно зависят от ресурса, запрос «*» полезен только как метод типа «ping» или «no-op»; он не делает ничего, кроме того, что позволяет клиенту проверить возможности сервера. Например, это можно использовать для проверки прокси-сервера на соответствие HTTP / 1.1 (или его отсутствие).

Если Request-URI не является звездочкой, запрос OPTIONS применяется только к параметрам, которые доступны при взаимодействии с этим ресурсом.

Ответ 200 ДОЛЖЕН включать любые поля заголовка, которые указывают дополнительные функции, реализованные сервером и применимые к этому ресурсу (например, Разрешить), возможно, включая расширения, не определенные в этой спецификации. Тело ответа, если таковое имеется, ДОЛЖНО также включать информацию о вариантах связи. Формат такого тела не определяется данной спецификацией, но может быть определен в будущих расширениях HTTP. Согласование содержимого МОЖЕТ использоваться для выбора подходящего формата ответа. Если тело ответа не включено, ответ ДОЛЖЕН включать поле Content-Length со значением поля "0".

Поле заголовка запроса Max-Forwards МОЖЕТ использоваться для нацеливания на конкретный прокси в цепочке запросов. Когда прокси-сервер получает запрос OPTIONS на absoluteURI, для которого разрешена пересылка запроса, он ДОЛЖЕН проверять поле Max-Forwards. Если значение поля Max-Forwards равно нулю ("0"), прокси-сервер НЕ ДОЛЖЕН пересылать сообщение; вместо этого прокси-сервер ДОЛЖЕН отвечать своими собственными параметрами связи. Если значение поля Max-Forwards является целым числом больше нуля, прокси-сервер ДОЛЖЕН уменьшить значение поля при пересылке запроса. Если в запросе нет поля Max-Forwards, то перенаправленный запрос НЕ ДОЛЖЕН включать в себя поле Max-Forwards.

9.4 ГОЛОВА

Метод HEAD идентичен GET, за исключением того, что сервер НЕ ДОЛЖЕН возвращать тело сообщения в ответе. Метаинформация, содержащаяся в заголовках HTTP в ответ на запрос HEAD, ДОЛЖНА быть идентична информации, отправленной в ответ на запрос GET. Этот метод можно использовать для получения метаинформации об объекте, подразумеваемом запросом, без передачи самого тела объекта. Этот метод часто используется для проверки гипертекстовых ссылок на достоверность, доступность и недавние изменения.

Ответ на запрос HEAD МОЖЕТ быть кэшируемым в том смысле, что информация, содержащаяся в ответе, МОЖЕТ использоваться для обновления ранее кэшированного объекта из этого ресурса. Если новые значения полей указывают на то, что кэшированный объект отличается от текущего объекта (на что указывает изменение Content-Length, Content-MD5, ETag или Last-Modified), тогда кэш ДОЛЖЕН рассматривать запись кэша как устаревшую.

OPTIONSметод возвращает информацию об API (методы / тип содержимого)

HEADметод возвращает информацию о ресурсе (версия / длина / тип)

Ответ сервера

ПАРАМЕТРЫ

HTTP/1.1 200 OK
Allow: GET,HEAD,POST,OPTIONS,TRACE
Content-Type: text/html; charset=UTF-8
Date: Wed, 08 May 2013 10:24:43 GMT
Content-Length: 0

ГОЛОВА

HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Type: text/html; charset=UTF-8
Date: Wed, 08 May 2013 10:12:29 GMT
ETag: "780602-4f6-4db31b2978ec0"
Last-Modified: Thu, 25 Apr 2013 16:13:23 GMT
Content-Length: 1270

• OPTIONS Определение, какие методы HTTP поддерживает ресурс, например, можем ли мы УДАЛИТЬ или обновить его с помощью PUT?
• HEADПроверка, изменился ли ресурс. Это полезно при поддержке кэшированной версии ресурса.
• HEAD Получение метаданных о ресурсе, например, о его типе носителя или размере, прежде чем производить, возможно, дорогостоящее извлечение
• HEAD, OPTIONSПроверка того, существует ли ресурс и доступен ли он. Например, проверка ссылок, отправленных пользователем, в приложении

Вот красивая и краткая статья о том, как HEAD и OPTIONS вписываются в архитектуру RESTful.

OPTIONS сообщает вам такие вещи, как «Какие методы разрешены для этого ресурса».

HEAD получает заголовок HTTP, который вы получили бы, если бы сделали запрос GET, но без тела. Это позволяет клиенту определять информацию кэширования, какой тип контента будет возвращен, какой код состояния будет возвращен. Доступность - это лишь небольшая часть этого.