Методы API RESTful; ГОЛОВА И ВАРИАНТЫ

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

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

Если кто-то может прояснить * эти глаголы, это было бы очень оценено.

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

ОТВЕТЫ

Ответ 1

В соответствии с: 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".

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

9.4 HEAD

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

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

Ответ 2

ОПЦИИ сообщают вам такие вещи, как "Какие методы разрешены для этого ресурса".

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

Ответ 3

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

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

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

OPTIONS

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.