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

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

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

Основные принципы HTTP изложены в RFC 9110. Помимо стандартных методов существуют расширения для WebDAV, работы с календарями, управления версиями и других протоколов. В июне 2026 года был утверждён новый метод QUERY, разработанный для сложных запросов с содержимым в теле.

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

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

Безопасным считается метод, который не должен изменять состояние ресурса по запросу клиента. К этой категории относятся GET, HEAD, OPTIONS, TRACE и QUERY.

Речь не идёт о защите от взлома. Сервер может вести логи, собирать статистику или обновлять внутренние показатели. Важно, что клиент не запрашивает изменение самого ресурса.

Идемпотентность означает, что многократное выполнение метода даёт тот же результат, что и однократное. GET, HEAD, PUT, DELETE, OPTIONS, TRACE и QUERY обладают этим свойством.

Ответы сервера при повторных запросах могут отличаться. Первый DELETE успешно удалит ресурс, второй вернёт сообщение о его отсутствии. Конечное состояние системы при этом останется идентичным.

GET

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

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

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

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

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

HEAD

HEAD аналогичен GET, но сервер не возвращает тело ответа.

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

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

Метод часто воспринимают как облегчённую версию GET, но экономия касается в первую очередь сетевого трафика. Backend может выполнить практически те же операции, что и при обычном GET, просто не отправляя тело ответа.

POST

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

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

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

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

POST также применяют для сложного поиска. Этот подход долгое время использовался, когда параметры уже неудобно передавать в URL. Новый метод QUERY был создан в том числе для того, чтобы безопасные операции чтения не приходилось маскировать под POST.

PUT

PUT передаёт новое представление ресурса по известному адресу. Его можно воспринимать как команду «установи ресурс в это состояние».

Основное отличие от PATCH заключается в семантике изменения. PUT описывает новое состояние ресурса целиком, тогда как PATCH передаёт набор частичных правок.

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

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

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

PATCH

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

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

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

Сам PATCH не определяет формат тела. Сервер и клиент должны заранее договориться о способе описания изменений.

Один распространённый вариант называется JSON Merge Patch и описан в RFC 7396. Клиент передаёт объект с изменяемыми полями. Формат удобен для простых структур, но значение null используется для удаления поля, а массивы обычно приходится заменять целиком.

Другой вариант — JSON Patch (RFC 6902). Вместо фрагмента объекта клиент отправляет последовательность операций add, remove, replace, move, copy и test. Такой подход удобнее для точечных изменений сложных документов и массивов.

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

DELETE

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

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

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

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

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

OPTIONS

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

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

В браузерах OPTIONS чаще всего встречается при CORS. Перед некоторыми межсайтовыми запросами браузер сначала отправляет предварительный запрос и проверяет, разрешает ли сервер нужный метод и заголовки.

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 зарегистрированы десятки дополнительных методов. Большинство появилось вместе со специализированными расширениями протокола.

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

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

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

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