W3docs

HTTP-методы

Метод GET запрашивает данные из указанного источника; метод POST отправляет данные для обработки в указанный источник.

HTTP (HyperText Transfer Protocol) был создан для обеспечения взаимодействия между клиентами и сервером. Он работает по модели «запрос — ответ»: клиент отправляет запрос, в котором указывает HTTP-метод (также называемый HTTP-глаголом), и этот метод сообщает серверу, какое действие следует выполнить над целевым ресурсом.

HTML-элемент <form> нативно поддерживает только два из этих методов — GET и POST — через атрибут method. Именно поэтому именно с этими двумя методами большинство HTML-разработчиков сталкиваются в первую очередь. Однако сам HTTP определяет ещё несколько методов (PUT, PATCH, DELETE, HEAD, OPTIONS, CONNECT), доступ к которым осуществляется через JavaScript (fetch) или серверную часть при построении REST API.

Два ключевых свойства: безопасность и идемпотентность

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

  • Безопасный — метод предназначен только для чтения. Он не должен изменять состояние сервера. Получение страницы никогда не должно создавать, обновлять или удалять что-либо. GET, HEAD и OPTIONS являются безопасными.
  • Идемпотентный — однократный и многократный вызов одного и того же запроса оказывает одинаковое воздействие на сервер. Отправка одного запроса DELETE для ресурса или отправка его пять раз приводит к одному результату — ресурс оказывается удалён в любом случае. Безопасные методы всегда идемпотентны, но метод может быть идемпотентным, не будучи безопасным (например, PUT и DELETE).

Вот как сравниваются распространённые методы:

МетодБезопасныйИдемпотентныйИмеет тело запросаТипичное применение
GETДаДаНетПолучение ресурса
HEADДаДаНетПолучение только заголовков
OPTIONSДаДаНетОпределение разрешённых методов / CORS preflight
POSTНетНетДаСоздание ресурса или отправка данных
PUTНетДаДаЗамена / обновление ресурса по известному URL
PATCHНетНе гарантируетсяДаЧастичное изменение ресурса
DELETEНетДаОбычно нетУдаление ресурса
Информация

PATCH не гарантированно является идемпотентным. В зависимости от того, как написан патч, он может быть идемпотентным (например, «установить status в active») или не быть им (например, «увеличить счётчик на 1»). Спецификация HTTP оставляет это на усмотрение реализации.

Метод GET

Метод GET запрашивает данные из указанного источника. Он является безопасным и идемпотентным: только читает данные и никогда ничего не изменяет на сервере. Запросы GET могут кэшироваться и сохраняются в истории браузера. Их также можно добавлять в закладки.

Его никогда не следует использовать для передачи конфиденциальных данных, поскольку строка запроса является частью URL (который записывается в журналы, кэшируется и сохраняется в закладках). Запросы GET имеют практические ограничения по длине и должны использоваться исключительно для получения данных.

Опасно

Строки запроса (пары имя/значение) передаются в URL запроса GET.

Пример поля ввода текста с методом get

<!DOCTYPE html>
<html>
  <head>
    <title>Title of the document</title>
  </head>
  <body>
    <form action="/form/submit" method="get">
      First name:
      <input type="text" name="username" placeholder="Your name" />
      <br />
      <br />
      <input type="submit" value="Submit" />
    </form>
  </body>
</html>

Метод POST

Метод POST отправляет данные для обработки в указанный источник. Он не является ни безопасным, ни идемпотентным: он может изменять состояние сервера, а повторная отправка одной и той же формы обычно создаёт две записи — именно поэтому браузеры предупреждают вас перед повторной отправкой данных POST. В отличие от метода GET, запросы POST никогда не кэшируются, не сохраняются в истории браузера и не могут быть добавлены в закладки. Кроме того, запросы POST не имеют ограничений по длине URL, хотя серверы, как правило, устанавливают собственные ограничения на размер тела запроса.

Опасно

Строки запроса (пары имя/значение) передаются в теле HTTP-сообщения запроса POST.

Пример формы с методом "post"

<!DOCTYPE html>
<html>
  <head>
    <title>Title of the document</title>
  </head>
  <body>
    <form action="/form/submit" method="post">
      First name:
      <input type="text" name="username" placeholder="Your name" />
      <br /><br />
      <input type="submit" value="Submit" />
    </form>
  </body>
</html>

Сравнение методов GET и POST

ФункцияGETPOST
Кнопка «Назад» / ПерезагрузкаБезопаснаПри перезагрузке страницы данные формы будут отправлены повторно. В этом случае браузер должен предупредить, что данные будут отправлены снова.
Возможность добавления в закладкиДаНет
Возможность кэшированияДаНет
Тип кодировкиapplication/x-www-form-urlencodedapplication/x-www-form-urlencoded или multipart/form-data
ИсторияОстаётся в истории браузера.Не остаётся в истории браузера.
Ограничения длины данныхПри отправке данных метод GET добавляет их к URL. Длина URL ограничена (максимальная длина URL — 2048 символов).Не имеет ограничений по длине URL, хотя серверы, как правило, устанавливают собственные ограничения на размер тела.
Ограничения типа данныхПреимущественно символы ASCII, хотя UTF-8 поддерживается через процентное кодирование.Не имеет ограничений. Допускаются и двоичные данные.
БезопасностьМенее безопасен, чем POST, так как отправляемые данные являются частью URL.POST безопаснее GET, поскольку данные не отображаются в URL или истории браузера. Однако оба метода передают данные в открытом виде по HTTP и требуют HTTPS для реальной безопасности.
ВидимостьДанные видны всем в URL.Не показывает данные в URL.

Примечание HTML-элемент <form> нативно поддерживает только GET и POST через атрибут method. Для использования PUT, PATCH или DELETE запрос обычно отправляется с помощью JavaScript (fetch) или серверный фреймворк переопределяет метод.

HEAD, OPTIONS и CONNECT

Помимо GET и POST, HTTP определяет ряд других методов. Три из них описаны здесь; ориентированные на работу с ресурсами методы PUT, PATCH и DELETE рассматриваются в отдельных разделах.

МетодБезопасныйИдемпотентныйОписание
HEADДаДаИдентичен GET, но сервер возвращает только HTTP-заголовки, без тела ответа.
OPTIONSДаДаЗапрашивает у сервера, какие методы и опции доступны для ресурса.
CONNECTНетНетУстанавливает туннель к серверу; используется прокси-серверами для HTTPS.

HEAD работает точно так же, как GET, но сервер не включает тело и возвращает только заголовки. Поскольку метод является безопасным и идемпотентным, он идеально подходит, когда нужны метаданные без загрузки всего ресурса — например, для проверки Content-Length большого файла перед загрузкой или для проверки доступности URL (его кода состояния) без передачи содержимого.

OPTIONS

OPTIONS запрашивает у сервера, что разрешено для ресурса. Ответ обычно содержит заголовок Allow со списком поддерживаемых методов (например, Allow: GET, POST, OPTIONS). Наиболее важное практическое применение — CORS preflight-запрос: прежде чем браузер отправит кросс-доменный PUT, DELETE или запрос с пользовательскими заголовками, он автоматически выполняет запрос OPTIONS, чтобы убедиться, что сервер разрешает фактический вызов. Писать OPTIONS-запросы вручную практически не приходится — за вас это делает браузер.

CONNECT

CONNECT указывает прокси-серверу установить прозрачный TCP/IP-туннель к пункту назначения, чаще всего для того, чтобы зашифрованный HTTPS-трафик мог проходить через прокси в нетронутом виде. Этот метод используется на уровне инфраструктуры, а не прикладного кода, поэтому вам почти никогда не придётся вызывать его напрямую.

Метод PUT

Метод PUT в основном используется для замены или обновления ресурса. Клиент отправляет URL целевого ресурса вместе с телом запроса, содержащим полное обновлённое представление этого ресурса. PUT также может создавать ресурс, когда URL ресурса определяет клиент, а не сервер.

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

Приведённый ниже пример просит сервер сохранить указанное тело JSON как ресурс по адресу /users/42:

HTTP-методы — пример запроса PUT

PUT /users/42 HTTP/1.1
Host: www.w3docs.com
Accept-Language: en-us
Connection: keep-alive
Content-Type: application/json
Content-Length: 54

{
  "name": "Jane Doe",
  "email": "[email protected]"
}

После сохранения тела сервер может ответить следующим образом:

HTTP-методы — пример ответа на запрос PUT

HTTP/1.1 200 OK
Date: Mon, 15 Jun 2026 14:53:57 GMT
Content-Type: application/json
Content-Length: 54
Connection: keep-alive

{
  "name": "Jane Doe",
  "email": "[email protected]"
}

Метод PATCH

Метод PATCH используется для частичного изменения ресурса. В отличие от PUT, ему не нужен весь ресурс — тело содержит только вносимые изменения.

PATCH не является безопасным, и не гарантированно является идемпотентным: в зависимости от формата патча он может давать или не давать одинаковый результат при повторении. Патч вида «установить status в active» идемпотентен, а патч вида «добавить 1 к views» — нет. Коллизии между двумя запросами PATCH также могут быть опасны, поскольку некоторые форматы патчей предполагают применение изменений от общего базового состояния; в противном случае ресурс может оказаться повреждён.

Приведённый ниже пример изменяет только поле email пользователя, оставляя все остальные поля без изменений:

HTTP-методы — пример запроса PATCH

PATCH /users/42 HTTP/1.1
Host: www.w3docs.com
Content-Type: application/json
Content-Length: 31

{ "email": "[email protected]" }
HTTP/1.1 200 OK
Date: Mon, 15 Jun 2026 14:53:57 GMT
Content-Type: application/json
Connection: keep-alive

Метод DELETE

Как следует из названия, этот метод удаляет ресурс, идентифицируемый по URL. DELETE не является безопасным, но является идемпотентным: после удаления ресурса повторный вызов DELETE оставляет его удалённым — конечное состояние одинаково. (Повторные вызовы могут возвращать другой код состояния, например 404 Not Found при второй попытке, но состояние сервера больше не изменяется.)

Приведённый ниже пример просит сервер удалить пользователя по адресу /users/42:

Пример запроса DELETE

DELETE /users/42 HTTP/1.1
Host: www.w3docs.com
Accept-Language: en-us
Connection: keep-alive

После удаления ресурса сервер обычно отвечает 204 No Content — статус успеха без тела ответа:

Пример ответа на запрос DELETE

HTTP/1.1 204 No Content
Date: Mon, 15 Jun 2026 14:53:57 GMT
Connection: keep-alive

Ответ 200 OK (опционально с телом, описывающим удалённый ресурс) также является допустимым ответом на DELETE. Полный список кодов состояния см. в разделе HTTP-сообщения о статусе.

Практика

Практика
Какие из этих HTTP-методов являются идемпотентными?
Какие из этих HTTP-методов являются идемпотентными?
Was this page helpful?