Я пишу модуль API RESTful для приложения на PHP, и я немного смешался с глаголами HEAD и OPTIONS .
OPTIONSИспользуется для получения доступных HTTP-глаголов для данного ресурса?HEADИспользуется для определения того, доступен ли данный ресурс?
Если бы кто-то мог прояснить * эти глаголы, это было бы очень оценено.
* Прояснение было в отношении архитектур API RESTful, повторно предназначающих 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 СЛЕДУЕТ включать любые поля заголовка, которые указывают дополнительные функции, реализованные сервером и применимые к этому ресурсу (например, Allow), возможно, включая расширения, не определенные этой спецификацией. Орган реагирования, если таковой имеется, ДОЛЖЕН также включать информацию об опциях связи. Формат для такого органа не определяется этой спецификацией, но может быть определен будущими расширениями HTTP. Согласование содержимого МОЖЕТ использоваться для выбора соответствующего формата ответа. Если тело ответа не включено, ответ ДОЛЖЕН включать поле Content-Length с полем значения «0».
Поле заголовка запроса «Макс-вперед» МОЖЕТ использоваться для таргетинга определенного прокси-сервера в цепочке запросов. Когда прокси получает запрос OPTIONS на абсолютномURI, для которого разрешена пересылка запроса, прокси ДОЛЖЕН проверять поле 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), тогда кеш ДОЛЖЕН рассматривать запись в кеше как устаревшую.
ОПЦИИ сообщают вам такие вещи, как «Какие методы разрешены для этого ресурса».
HEAD получает заголовок HTTP, который вы получите, если вы сделали запрос GET, но без тела. Это позволяет клиенту определять информацию кэширования, какой тип содержимого будет возвращен, какой код состояния будет возвращен. Доступность – лишь малая его часть.
Метод 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.