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

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

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

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

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

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