Source: Http methods
← Renderedmarkdown source:
---
description: Методы в http
tags: http
title: Http methods
---
[Основная статья](https://developer.mozilla.org/ru/docs/Web/HTTP/Methods)
- Метод `GET` запрашивает представление ресурса. Запросы с использованием этого метода могут только извлекать данные.
- `HEAD` запрашивает ресурс так же, как и метод `GET`, но без тела ответа.
- `POST` используется для отправки сущностей к определённому ресурсу. Часто вызывает изменение состояния или какие-то побочные эффекты на сервере.
- `PUT` заменяет все текущие представления ресурса данными запроса.
- `DELETE` удаляет указанный ресурс.
- `CONNECT` устанавливает "туннель" к серверу, определённому по ресурсу.
- `OPTIONS` используется для описания параметров соединения с ресурсом.
- `TRACE` выполняет вызов возвращаемого тестового сообщения с ресурса.
- `PATCH` используется для частичного изменения ресурса.
## Некоторые свойства методов
### [Безопасный метод](https://developer.mozilla.org/ru/docs/Glossary/safe)
Метод HTTP является безопасным, если он не меняет состояние сервера. Другими словами, безопасный метод проводит операции "только чтение" (read-only). Несколько следующих методов HTTP безопасные: GET, HEAD или OPTIONS. Все безопасные методы являются также идемпотентными, как и некоторые другие, но при этом небезопасные, такие как PUT или DELETE.
Даже если безопасные методы являются по существу "только для чтения", сервер всё равно может сменить своё состояние: например, он может сохранять статистику. Что существенно, так то, когда клиент вызывает безопасный метод, то он не запрашивает никаких изменений на сервере, и поэтому не создаёт дополнительную нагрузку на сервер. Браузеры могут вызывать безопасные методы, не опасаясь причинить вред серверу: это позволяет им выполнять некоторые действия, например, предварительная загрузка без риска. Поисковые роботы также полагаются на вызовы безопасных методов.
Безопасные методы не обязательно должны обрабатывать только статичные файлы; сервер может генерировать ответ "на-лету", пока скрипт, генерирующий ответ, гарантирует безопасность: он не должен вызывать внешних эффектов, таких как формирование заказов, отправка писем и др..
Правильная реализация безопасного метода - это ответственность серверного приложения, потому что сам веб-сервер, будь то Apache, nginx, IIS это соблюсти не сможет. В частности, приложение не должно разрешать изменение состояния сервера запросами GET.
### [Идемпотентный метод](https://developer.mozilla.org/ru/docs/Glossary/Idempotent)
Метод HTTP является идемпотентным, если повторный идентичный запрос, сделанный один или несколько раз подряд, имеет один и тот же эффект, не изменяющий состояние сервера. Другими словами, идемпотентный метод не должен иметь никаких побочных эффектов (side-effects), кроме сбора статистики или подобных операций. Корректно реализованные методы GET, HEAD, PUT и DELETE идемпотентны, но не метод POST. Также все безопасные методы являются идемпотентными.
Для идемпотентности нужно рассматривать только изменение фактического внутреннего состояния сервера, а возвращаемые запросами коды статуса могут отличаться: первый вызов DELETE вернёт код 200, в то время как последующие вызовы вернут код 404. Из идемпотентности DELETE неявно следует, что разработчики не должны использовать метод DELETE при реализации RESTful API с функциональностью удалить последнюю запись.
Обратите внимание, что идемпотентность метода не гарантируется сервером, и некоторые приложения могут нарушать ограничение идемпотентности.
### [Кешируемые методы](https://developer.mozilla.org/ru/docs/Glossary/cacheable)
Кешируемые ответы - это HTTP-ответы, которые могут быть закешированы, то есть сохранены для дальнейшего восстановления и использования позже, тем самым снижая число запросов к серверу. Не все HTTP-ответы могут быть закешированы. Вот несколько ограничений:
- Метод, используемый в запросе, кешируемый, если это GET или HEAD. Ответ для POST или PATCH запросов может также быть закеширован, если указан признак "свежести" данных и установлен заголовок Content-Location (en-US), но это редко реализуется. Например, Firefox не поддерживает это [согласно](https://bugzilla.mozilla.org/show_bug.cgi?id=109553). Другие методы, такие как PUT и DELETE не кешируемые, и результат их выполнения не кешируется
- Коды ответа, известные системе кеширования, которые рассматриваются как кешируемые: 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501.
- Отсутствуют специальные заголовки в ответе, которые предотвращают кеширование: например, Cache-Control.
Обратите внимание, что некоторые некешируемые запросы-ответы к определённым URI могут сделать недействительным (инвалидируют) предыдущие закешированные ответы на тех же URI. Например, PUT к странице pageX.html инвалидируют все закешированные ответы GET или HEAD запросов к этой странице.
### [Методы, используемые в html-формах](https://developer.mozilla.org/ru/docs/Learn/Forms)
## Таблица методов
| | 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` не был сделан.
- [[руководство-по-html-формам]]
- [[http]]
[http-заголовки]: http-%D0%B7%D0%B0%D0%B3%D0%BE%D0%BB%D0%BE%D0%B2%D0%BA%D0%B8 "Http заголовки"
[http]: ../lists/http "Http"
[руководство-по-html-формам]: %D1%80%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE-%D0%BF%D0%BE-html-%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D0%BC "Руководство по html формам"