Метод get

Метод GET предполагает извлечение любой информации (в форме объекта), заданной Request-URI. Если Request-URI относится к процессу, генерирующему данные, то в результате в виде объекта будут присланы эти данные, а не исходный текст самого процесса, если только этот текст не является результатом самого процесса.

Семантика метода меняется на условный GET, если сообщение­запрос включает в себя поля заголовка If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match или If-Range. Метод условного GET запрашивает, пересылку объекта только при выполнении требований, описанных в соответствующих полях заголовка. Метод условного GET имеет целью уменьшить ненужное использование сети путем разрешения актуализации кэшированых объектов без посылки множественных запросов или пересылки данных, которые уже имеются у клиента. Семантика метода GET меняется на частичный GET, если сообщение запроса включает в себя поле заголовка Range. Метод частичного GET ориентирован на уменьшение ненужного сетевого обмена, допуская пересылку лишь части объекта, которая нужна клиенту, и не пересылая уже имеющихся частей.

Отклик на запрос GET буферизуется тогда и только тогда, когда это согласуется с требованиями буферизации.

Метод head

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

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

Метод post

Метод POST используется при подаче заявки серверу принять вложенный в запрос объект в качестве нового вторичного ресурса, идентифицированного Request-URI в RequestLine. POST создан для обеспечения однородной схемы реализации следующих функций:

• аннотация существующего ресурса;

• помещение сообщения на электронную доску объявлений, в группу новостей, почтовый список или какуюто другую группу статей;

• выдача блока данных, такого, как при передаче формы процессу ее обработки;

• расширение базы данных с помощью операции добавления (append).

Реальная операция, выполняемая методом POST, определяется сервером и обычно зависит от Request-URI. Присланный объект является вторичным по отношению к URI в том же смысле, в каком файл является вторичным по отношению к каталогу, в котором он находится, статья новостей — вторичной по отношению к группе новостей, куда она помещена, или запись — по отношению к базе данных.

Операция, выполняемая методом POST, может не иметь последствий для ресурса, который может быть идентифицирован URI. В этом случае приемлемым откликом является 200 (OK) или 204 (No Content — никакого содержимого), в зависимости от того, включает ли в себя отклик объект, описывающий ресурс.

Если ресурс был создан на исходном сервере, отклик должен быть равен 201 (Created — создан) и содержать объект, который описывает статус запроса и относится к новому ресурсу и заголовку Location.

Отклики на этот метод не могут кэшироваться, если только не содержат поля заголовка Cache-Control или Expires. Однако отклик 303 может быть использован для того, чтобы направить агента пользователя для извлечения кэшируемого ресурса.

Запросы POST должны подчиняться требованиям, предъявляемым к передаче сообщений.