HTTP-методы простыми словами: GET, POST, PUT, PATCH, DELETE и новый QUERY

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

На ранних этапах обучения HTTP часто упрощают до схемы: «GET читает, POST создаёт, PUT заменяет, DELETE удаляет». Хотя это и полезно для первичного понимания, данная схема неполна и может вводить в заблуждение. Например, POST не всегда создаёт ресурс, PUT может использоваться для создания, DELETE не обязательно стирает данные физически, а PATCH вообще не предписывает конкретный способ изменения. Истинная семантика HTTP подробно описана в RFC 9110.

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

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

Прежде чем углубляться в детали каждого метода, важно понимать два ключевых свойства:

• Безопасный метод: HTTP-метод считается безопасным, если он не должен изменять состояние ресурса на сервере. К безопасным относятся GET, HEAD, OPTIONS, TRACE и QUERY. Важно отметить, что это не имеет отношения к защите от атак, а лишь означает, что клиент не запрашивает изменения самого ресурса (сервер может, например, записать данные в журнал или обновить статистику).
• Идемпотентный метод: Идемпотентный метод можно повторить несколько раз, и конечный эффект на сервере будет таким же, как и при однократном выполнении. К идемпотентным относятся GET, HEAD, PUT, DELETE, OPTIONS, TRACE и QUERY. Ответы сервера при повторных запросах могут отличаться (например, первый DELETE удаляет ресурс, а второй сообщает, что его уже нет), но состояние ресурса остаётся прежним.

Метод	Основное назначение	Безопасный	Идемпотентный
GET	получение ресурса	да	да
HEAD	получение заголовков без тела	да	да
POST	передача данных на обработку	нет	нет
PUT	замена ресурса	нет	да
PATCH	частичное изменение	нет	нет
DELETE	удаление ресурса	нет	да
OPTIONS	получение возможностей ресурса	да	да
TRACE	диагностика HTTP-цепочки	да	да
CONNECT	создание туннеля	нет	нет
QUERY	безопасный запрос с телом	да	да

GET

Метод GET используется для получения представления ресурса. Именно с помощью GET браузеры загружают веб-страницы и изображения, приложения получают данные через API, а поисковые системы запрашивают результаты по заданным критериям.

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

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

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

GET также не подходит для сложных, структурированных запросов с большим телом, так как семантика тела GET-запроса не стандартизирована, и многие компоненты инфраструктуры могут некорректно обрабатывать такие запросы. Для этих целей в 2026 году был предложен метод QUERY.

HEAD

Метод HEAD очень похож на GET, но сервер в ответ не возвращает тело ресурса.

Он применяется, когда клиенту нужна только метаинформация о ресурсе — например, его статус, тип содержимого, размер, дата последнего изменения или ETag, без необходимости загружать весь файл или страницу.

HEAD является безопасным и идемпотентным. Заголовки ответа должны максимально соответствовать тем, которые сервер отправил бы при GET-запросе.

Хотя HEAD часто воспринимается как «облегчённая» версия GET, экономия в основном относится к сетевому трафику. На стороне бэкенда может выполняться почти та же работа, что и для GET, прежде чем тело ответа будет просто отброшено.

POST

Метод POST используется для отправки данных ресурсу для обработки. Его назначение шире, чем просто «создать новый объект».

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

POST не является ни безопасным, ни идемпотентным. Повторная отправка одного и того же запроса может привести к многократному выполнению операции. Например, две отправки формы могут создать две записи, а повторный платёжный запрос — провести вторую транзакцию, если API не имеет встроенной защиты.

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

POST также долгое время использовался для выполнения сложных поисковых запросов, когда параметры не умещались в URL. Однако новый метод QUERY призван устранить эту необходимость, предлагая безопасный способ выполнения таких запросов с телом.

PUT

Метод PUT используется для полной замены ресурса по известному URI. Его можно интерпретировать как команду «сделать ресурс полностью таким, как описано в теле запроса».

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

PUT является идемпотентным. Повторные запросы с одним и тем же телом должны приводить к одному и тому же конечному состоянию ресурса.

Этот метод может использоваться не только для обновления. Если ресурс по указанному адресу отсутствует и сервер разрешает такое создание, PUT может создать новый ресурс. Таким образом, упрощённая формула «POST создаёт, PUT обновляет» не всегда точна.

При разработке API важно определить, как сервер будет обрабатывать поля, не переданные в PUT-запросе. Если операция заявлена как полная замена, сохранение старых полей без явного указания может привести к поведению, похожему на PATCH.

PATCH

Метод PATCH предназначен для частичного изменения ресурса и определён в RFC 5789.

В отличие от PUT, клиенту не нужно отправлять полное представление объекта. Вместо этого передаются только те изменения, которые необходимо применить.

PATCH по определению не является идемпотентным. Хотя некоторые конкретные PATCH-операции могут быть идемпотентными (например, установка фиксированного значения), другие (например, увеличение счётчика или добавление элемента в список) могут менять состояние при каждом повторении.

Сам метод PATCH не определяет формат тела запроса. Клиент и сервер должны заранее договориться о том, как описываются изменения. Два распространённых формата:

• JSON Merge Patch (RFC 7396): Клиент отправляет объект с изменяемыми полями. Удобен для простых структур, но значение null используется для удаления поля, а массивы обычно заменяются целиком.
• JSON Patch (RFC 6902): Клиент передаёт последовательность операций (add, remove, replace, move, copy и test). Этот подход удобнее для точечных изменений сложных документов и массивов.

Сервер может уведомить о поддерживаемых форматах с помощью заголовка Accept-Patch.

DELETE

Метод DELETE запрашивает удаление ресурса по указанному URI.

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

Так называемое «мягкое удаление» широко используется, когда необходимо восстановить данные после ошибки, сохранить историю действий или выполнить требования к срокам хранения.

DELETE является идемпотентным. Это свойство относится к конечному эффекту, а не к ответу сервера. Первый запрос может быть успешным, а повторный — сообщить, что ресурс уже не существует, но конечное состояние (ресурс удалён) остаётся тем же.

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

OPTIONS

Метод OPTIONS запрашивает информацию о возможностях сервера или конкретного ресурса.

Через заголовок Allow сервер может сообщить, какие HTTP-методы поддерживаются для данного endpoint. Дополнительные заголовки могут раскрывать и другие возможности, например, допустимые форматы для PATCH-запросов.

В браузерах OPTIONS чаще всего используется в контексте CORS (Cross-Origin Resource Sharing). Перед некоторыми межсайтовыми запросами браузер отправляет «предварительный» (preflight) запрос с методом OPTIONS, чтобы выяснить, разрешает ли сервер использование нужного метода и заголовков.

OPTIONS является безопасным и идемпотентным.

Сам факт доступности OPTIONS не создаёт серьёзной уязвимости. Скрытие поддерживаемых методов не заменяет необходимость в надёжной аутентификации и проверке прав доступа.

TRACE

Метод TRACE был создан как диагностический механизм. Сервер в ответ возвращает клиенту точное представление полученного запроса, что позволяет анализировать, как данные проходят через промежуточные HTTP-компоненты (прокси, балансировщики).

Стандарт относит TRACE к безопасным и идемпотентным методам.

В обычных веб-приложениях эта диагностическая функция почти никогда не требуется. Из-за исторических проблем безопасности и небольшой практической пользы TRACE часто отключают на публичных серверах.

Современные браузерные API также строго ограничивают возможность отправки TRACE-запросов из JavaScript, поэтому в прикладной веб-разработке этот метод встречается крайне редко.

CONNECT

Метод CONNECT предназначен для создания туннеля через HTTP-посредника (обычно прокси-сервер).

Типичный сценарий: клиент просит прокси установить соединение с другим узлом, после чего трафик проходит через созданный туннель. Именно так традиционно устанавливается HTTPS-соединение через обычный HTTP-прокси.

CONNECT не считается безопасным или идемпотентным.

Для обычного веб-сайта этот метод чаще всего не нужен. Однако для прокси, шлюзов и некоторых современных протоколов CONNECT остаётся важным рабочим механизмом.

Разрешать произвольный CONNECT без контроля назначения опасно, поскольку неправильно настроенный сервер может фактически превратиться в открытый прокси.

QUERY

QUERY стал самым значимым дополнением к основному набору HTTP-методов за последние годы. Он был стандартизирован в июне 2026 года в RFC 10008.

Метод QUERY предназначен для выполнения безопасных запросов, которым требуется передача содержимого в теле.

До появления QUERY разработчики сталкивались с дилеммой: простой поиск хорошо ложился на GET, сохраняя правильную семантику чтения. Однако сложный запрос с множеством фильтров, вложенными условиями или объёмным выражением удобнее было передавать в теле запроса. Для таких задач часто использовали POST.

POST технически решал проблему, но сообщал инфраструктуре неверную семантику. Прокси, кеши или библиотеки воспринимали это как потенциально изменяющую состояние операцию, хотя сервер просто выполнял поиск.

QUERY устраняет этот недостаток. Метод является безопасным и идемпотентным, при этом он изначально предназначен для использования с телом запроса.

RFC 10008 также определяет правила кеширования для QUERY. Содержимое запроса участвует в формировании ключа кеша, поскольку два обращения к одному URI с разными телами могут представлять совершенно разные запросы.

Для QUERY появился заголовок Accept-Query, через который сервер может информировать о поддерживаемых форматах содержимого.

Этот метод хорошо подходит для поисковых движков, аналитических систем и API со сложной фильтрацией. Пока QUERY очень новый, поэтому часть старых серверов, прокси, библиотек и API-шлюзов может его не поддерживать или обрабатывать менее эффективно, чем привычные GET и POST.

WebDAV и другие методы

Привычные GET, POST, PUT и DELETE составляют лишь часть всего протокола HTTP.

В официальном реестре IANA зарегистрированы десятки дополнительных методов, большинство из которых появились в рамках специализированных расширений HTTP.

Например, WebDAV добавляет PROPFIND для получения свойств ресурсов, PROPPATCH для их изменения, MKCOL для создания коллекций, COPY и MOVE для копирования и перемещения, а также LOCK и UNLOCK для управления блокировками.

Другие расширения внесли ещё больше методов: MKCALENDAR для календарных коллекций, ACL для управления списками доступа, а также CHECKIN, CHECKOUT, VERSION-CONTROL, MERGE и ряд других для версионирования ресурсов.

В реестре также встречается PRI, связанный с HTTP/2. Для обычного API такой метод использовать не нужно.

Запоминать весь этот список наизусть нет необходимости. Для большинства веб-разработчиков достаточно хорошо понимать основной набор и помнить, что HTTP является расширяемым протоколом. Метод QUERY является наглядным примером того, как протокол продолжает развиваться спустя десятилетия после появления первых GET и POST.