Методы RESTful API; HEAD & OPTIONS

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

  • OPTIONS  используется для получения доступных команд HTTP для данного ресурса?
  • HEAD используется для определения доступности данного ресурса?

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

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

3 57
http api php database-restore

3 ответа:

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

9.2 варианты

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

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

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

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

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

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

поле заголовка запроса Max-Forwards может использоваться для назначения определенного прокси в цепочке запросов. Когда прокси получает запрос параметров на absoluteURI, для которого разрешена переадресация запроса, прокси должен проверить поле Max-Forwards. Если значение поля Max-Forwards равно нулю ("0"), прокси-сервер не должен пересылать сообщение; вместо этого прокси-сервер должен отвечать своими собственными параметрами связи. Если значение поля Max-Forwards является целым числом, большим нуля, прокси-сервер должен уменьшить значение поля при пересылке запроса. Если в запросе нет поля Max-Forwards, то переадресованный запрос не должен содержать a Макс-поле форвардов.

9.4 HEAD

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

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

34

параметры говорят вам такие вещи, как "какие методы разрешены для этого ресурса".

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

22

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 и опции вписываются в архитектуру RESTful.

12