Http methods

Метод GET запрашивает представление ресурса. Запросы с использованием этого метода могут только извлекать данные.
HEAD запрашивает ресурс так же, как и метод GET, но без тела ответа.
POST используется для отправки сущностей к определённому ресурсу. Часто вызывает изменение состояния или какие-то побочные эффекты на сервере.
PUT заменяет все текущие представления ресурса данными запроса.
DELETE удаляет указанный ресурс.
CONNECT устанавливает “туннель” к серверу, определённому по ресурсу.
OPTIONS используется для описания параметров соединения с ресурсом.
TRACE выполняет вызов возвращаемого тестового сообщения с ресурса.
PATCH используется для частичного изменения ресурса.

Некоторые свойства методов

Безопасный метод

Метод HTTP является безопасным, если он не меняет состояние сервера. Другими словами, безопасный метод проводит операции “только чтение” (read-only). Несколько следующих методов HTTP безопасные: GET, HEAD или OPTIONS. Все безопасные методы являются также идемпотентными, как и некоторые другие, но при этом небезопасные, такие как PUT или DELETE.

Даже если безопасные методы являются по существу “только для чтения”, сервер всё равно может сменить своё состояние: например, он может сохранять статистику. Что существенно, так то, когда клиент вызывает безопасный метод, то он не запрашивает никаких изменений на сервере, и поэтому не создаёт дополнительную нагрузку на сервер. Браузеры могут вызывать безопасные методы, не опасаясь причинить вред серверу: это позволяет им выполнять некоторые действия, например, предварительная загрузка без риска. Поисковые роботы также полагаются на вызовы безопасных методов.

Безопасные методы не обязательно должны обрабатывать только статичные файлы; сервер может генерировать ответ “на-лету”, пока скрипт, генерирующий ответ, гарантирует безопасность: он не должен вызывать внешних эффектов, таких как формирование заказов, отправка писем и др..

Правильная реализация безопасного метода - это ответственность серверного приложения, потому что сам веб-сервер, будь то Apache, nginx, IIS это соблюсти не сможет. В частности, приложение не должно разрешать изменение состояния сервера запросами GET.

Идемпотентный метод

Метод HTTP является идемпотентным, если повторный идентичный запрос, сделанный один или несколько раз подряд, имеет один и тот же эффект, не изменяющий состояние сервера. Другими словами, идемпотентный метод не должен иметь никаких побочных эффектов (side-effects), кроме сбора статистики или подобных операций. Корректно реализованные методы GET, HEAD, PUT и DELETE идемпотентны, но не метод POST. Также все безопасные методы являются идемпотентными.

Для идемпотентности нужно рассматривать только изменение фактического внутреннего состояния сервера, а возвращаемые запросами коды статуса могут отличаться: первый вызов DELETE вернёт код 200, в то время как последующие вызовы вернут код 404. Из идемпотентности DELETE неявно следует, что разработчики не должны использовать метод DELETE при реализации RESTful API с функциональностью удалить последнюю запись.

Обратите внимание, что идемпотентность метода не гарантируется сервером, и некоторые приложения могут нарушать ограничение идемпотентности.

Кешируемые методы

Кешируемые ответы - это HTTP-ответы, которые могут быть закешированы, то есть сохранены для дальнейшего восстановления и использования позже, тем самым снижая число запросов к серверу. Не все HTTP-ответы могут быть закешированы. Вот несколько ограничений:

Метод, используемый в запросе, кешируемый, если это GET или HEAD. Ответ для POST или PATCH запросов может также быть закеширован, если указан признак “свежести” данных и установлен заголовок Content-Location (en-US), но это редко реализуется. Например, Firefox не поддерживает это согласно. Другие методы, такие как PUT и DELETE не кешируемые, и результат их выполнения не кешируется
Коды ответа, известные системе кеширования, которые рассматриваются как кешируемые: 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501.
Отсутствуют специальные заголовки в ответе, которые предотвращают кеширование: например, Cache-Control.

Обратите внимание, что некоторые некешируемые запросы-ответы к определённым URI могут сделать недействительным (инвалидируют) предыдущие закешированные ответы на тех же URI. Например, PUT к странице pageX.html инвалидируют все закешированные ответы GET или HEAD запросов к этой странице.

Методы, используемые в html-формах

Таблица методов

	GET	POST	DELETE	HEAD	PUT	PATCH
Запрос имеет тело	нет	да	**	нет	да	да
Успешный ответ имеет тело	да	да	**	нет	нет	да
Безопасный	да	нет	нет	да	нет	нет
Идемпотентный	да	нет	да	да	да	нет
Кешируемый	да	*	нет	да	нет	нет
Допускается в HTML-формах	да	да	нет	нет	нет	нет

* Только если включена информация о свежести сообщения ** Может

HTTP-метод POST предназначен для отправки данных на сервер. Тип тела запроса указывается в [http-заголовки] Content-Type.

Разница между PUT и POST состоит в том, что PUT является идемпотентным: повторное его применение даёт тот же результат, что и при первом применении (то есть у метода нет побочных эффектов), тогда как повторный вызов одного и того же метода POST может иметь такие эффекты, как например, оформление одного и того же заказа несколько раз.

Запрос POST обычно отправляется через форму HTML и приводит к изменению на сервере. В этом случае тип содержимого выбирается путём размещения соответствующей строки в атрибуте enctype элемента <form> или formenctype атрибута элементов <input> или <button>:

Когда запрос POST отправляется с помощью метода, отличного от HTML-формы, — например, через XMLHttpRequest — тело может принимать любой тип. Как описано в спецификации HTTP 1.1, POST предназначен для обеспечения единообразного метода для покрытия следующих функций:

Аннотация существующих ресурсов
Публикация сообщения на доске объявлений, в новостной группе, в списке рассылки или в аналогичной группе статей;
Добавление нового пользователя посредством модальности регистрации;
Предоставление блока данных, например, результата отправки формы, процессу обработки данных;
Расширение базы данных с помощью операции добавления.

Метод запроса [http] PATCH частично изменяет ресурс.

В какой-то степени PATCH можно назвать аналогом концепта «обновить» (update) из CRUD (en-US) (но не стоит путать HTTP и CRUD (en-US) — это две разные вещи).

PATCH может как быть идемпотентным, так и не быть, в отличие от PUT, который всегда идемпотентен. Операция считается идемпотентной, если её многократное выполнение приводит к тому же результату, что и однократное выполнение. Например, если автоинкрементное поле является важной частью ресурса, то PUT перезапишет его (т.к. он перезаписывает всё), но PATCH может и не перезаписать.

PATCH (как и PUT) может иметь побочные эффекты на другие ресурсы.

Чтобы обозначить, что сервер поддерживает PATCH, можно добавить этот метод в список заголовков ответа Allow (en-US) или Access-Control-Allow-Methods (для CORS).

Другой (неявный) индикатор, что PATCH разрешён, является наличие заголовка Accept-Patch, где описано, в каком формате сервер принимает изменённые документы.

Метод запроса HTTP PUT создаёт новый ресурс или заменяет представление целевого ресурса, данными представленными в теле запроса.

Разница между PUT и POST в том, что PUT является идемпотентным, т.е. единичный и множественные вызовы этого метода, с идентичным набором данных, будут иметь тот же результат выполнения (без сторонних эффектов), в случае с POST, множественный вызов с идентичным набором данных может повлечь за собой сторонние эффекты.

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

Ответ на метод HEAD не должен содержать тело. Если это не так, то его следует игнорировать. Но даже в этом случае заголовки сущности, описывающие содержимое тела, например Content-Length, должны быть включены в ответ. Они не относятся к телу ответа на запрос HEAD, которое должно быть пустым, они относятся к телу ответа, полученный на аналогичный запрос с помощью метода GET.

Если результат запроса HEAD показывает, что кешированный после запроса GET ресурс устарел, то кеш становится недействительным, даже если запрос GET не был сделан.