HTTP_QUERY

1.

HTTP
QUERY
Новый стандартный HTTP-метод для сложных read-only запросов
RFC 10008 · The HTTP QUERY Method · Proposed Standard
Опубликован IETF 15 июня 2026 · J. Reschke, J. Snell, M. Bishop
Одной фразой: QUERY — это GET, которому разрешили иметь тело запроса.

2.

Зачем появился QUERY
У HTTP исторически было чёткое разделение ролей между GET и POST
GET
GET
Безопасный (safe) и идемпотентный способ что-то
узнать. Но нет определённой семантики тела запроса
— параметры только через URL.
PO
POST
Способ что-то сделать: создать, изменить, запустить
процесс. По умолчанию не safe и не идемпотентен —
повтор может значить «сделай ещё раз».
Проблема
Запрос по природе — просто чтение (логически GET), но слишком сложный для URL: много необязательных параметров, вложенные
фильтры, диапазоны дат, списки значений — или в фильтре чувствительные данные (СНИЛС, телефон), которые не хочется светить в URL и
логах.
Индустрия годами решала это неформально — POST /search, POST /_search (привет, Elasticsearch) — ценой потери гарантий «безопасной»
операции.
2

3.

Ключевые свойства QUERY
1
Safe
Как и GET, ничего не меняет на сервере.
2
Idempotent
Повторный запрос с тем же телом не создаёт новых побочных эффектов.
3
Есть тело
Формат не фиксирован жёстко (JSON, form-urlencoded) — достаточно явного Content-Type.
4
Ответ как у GET
Обычные статусы (200, 400, 404…) — новых кодов стандарт не вводит.
Кэш — не «из коробки»
У GET кэш ключуется по URL. У QUERY тело — часть запроса, поэтому для кэширования нужна доп. поддержка сервера/прокси (например, ContentDigest, RFC 9530).
3

4.

Сравнение методов
Метод
Safe
Idempotent
Тело
Кэш по умолчанию
Применение
GET
✓
✓
✕
да (по URL)
POST
✕
✕
✓
нет
создание / изменение / действие
PUT
✕
✓
✓
нет
полная замена ресурса
DELETE
✕
✓
✕
нет
удаление ресурса
QUERY
✓
✓
✓
нет (нужна доп. поддержка)
простое чтение по URL
сложный read-only запрос, не влезающий в URL
QUERY сочетает гарантии GET (safe, idempotent) с телом запроса — как у POST
4

5.

Как это выглядит
Пример: постраничный поиск по правам доступа с фильтром
РАНЬШЕ · длинный URL
GET /admin/permissions?page=0&size=20&snils=...&spSyncStatus=FAILED
&sortBy=CREATED_AT&sortType=DESC
С QUERY · формальная декларация «я безопасен»
QUERY /admin/permissions
Content-Type: application/json
{
"page": 0, "size": 20,
"filter": { "snils": "...", "spSyncStatus": "FAILED" },
"sort": { "by": "CREATED_AT", "direction": "DESC" }
200 OK
{ "items": [...],
"totalCount": 3 }
}
5

6.

Где имеет смысл применять
✓
Подходит
• Постраничный поиск со сложным фильтром: много
optional-полей, вложенные структуры, диапазоны, списки
• Фильтр содержит чувствительные данные, которые не
хочется видеть в URL и логах
• GraphQL-подобные запросы, полнотекстовый поиск,
агрегации
✕
Не подходит / рано
• Простой GET по id или 1–2 параметрам — там и так всё
хорошо
• Любая операция, реально меняющая состояние — это всё
ещё POST/PUT/DELETE
• Инфраструктура на пути (gateway, CDN, WAF) ещё не умеет
работать с этим методом
• Важно, чтобы клиент/прокси знали, что повтор безопасен
6

7.

Поддержка на сегодня
Стандарт совсем свежий, поэтому статус — раннее внедрение
Node.js
Поддерживается
Распознаёт метод QUERY на уровне HTTP-парсера с 2024 года.
OpenAPI 3.2
Поддерживается
Уже умеет описывать QUERY-эндпоинты в спецификации.
Spring Framework
В процессе
Константы QUERY в RequestMethod пока нет (PR #34993, issue #36988). Обходной путь: RequestMethod.valueOf("QUERY") — не
решение «из коробки».
Прежде чем использовать в проде — проверьте всю цепочку: балансировщик, gateway, ingress, а не только сам сервис. Если что-то по пути не знает
про метод, вернётся 405 или 501.
7

8.

Безопасность: на что обратить внимание
!
Старые допущения инфраструктуры ломаются
Часть инфраструктуры (WAF, прокси, логирование) годами исходила из допущения «есть тело → значит, вероятно, мутирующее». QUERY это
ломает: тело есть, а метод безопасный. Пока такие системы не обновлены — возможны пропуски при анализе тела в security-инструментах или
некорректное кэширование без учёта содержимого тела.
«Safe» ≠ без ограничений
«Safe» — про отсутствие побочных эффектов на сервере, а не про освобождение от лимитов на размер тела, rate-limit и валидацию входных
данных — их нужно применять так же, как к POST.
✓
Плюс: чувствительные данные фильтра уезжают в тело, а не в URL — меньше риска, что они осядут в access-логах или истории
браузера.
8

9.

Коротко
QUERY — новый стандартный HTTP-метод: как GET по гарантиям (safe, idempotent), но
с телом запроса, как у POST.
• Закрывает давний разрыв между «просто спросить» и «сложно спросить»
• Не замена GET/POST, а дополнительный инструмент для одного класса задач — сложных read-only запросов
• Стандарт свежий (июнь 2026), поддержка в экосистеме (в частности, в Spring) пока догоняет
• Использовать стоит осознанно, но держать в голове при проектировании новых эндпоинтов
Источники: RFC 10008 (rfc-editor.org/info/rfc10008, datatracker.ietf.org/doc/html/rfc10008) · issue spring-projects/spring-framework #36988 и PR #34993