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

Question

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

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

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

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

Answer 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».

Поле заголовка запроса 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), то кэш ДОЛЖЕН трактовать запись в кэше как устаревшую.

Answer 2

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

HEAD

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.

Answer 3

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

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