arenru
19 июля 2026 г.#http#web#api#backendдоступно на арабскомдоступно на английском

QUERY: первый новый HTTP-метод за много лет

В июне 2026 вышел RFC 10008 с методом QUERY — безопасный и кэшируемый запрос как GET, но с телом как у POST. Какую проблему он закрывает и когда его реально применять?

QUERY: первый новый HTTP-метод за много лет

В июне 2026 года IETF опубликовала стандарт RFC 10008, официально добавив в HTTP новый метод QUERY — первое пополнение такого рода со времён PATCH в 2010-м.

Старая проблема

Любой растущий API рано или поздно упирается в одно и то же: эндпоинт поиска или фильтрации, а все доступные варианты — с изъяном.

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

Знакомый итог: POST /search почти в каждом проекте — решение рабочее, но это обход протокола, а не его использование.

Что делает QUERY

Коротко: безопасен и идемпотентен как GET, несёт тело как POST.

QUERY /products HTTP/1.1
Content-Type: application/json

{
"filters": { "category": "electronics", "price_max": 500 },
"sort": "price_asc",
"limit": 20
}

Теперь протокол знает, что запрос — только чтение, и это даёт три прямых преимущества:

  1. Безопасные повторы — клиент или прокси может автоматически повторить запрос, не опасаясь частичного изменения состояния.
  2. Кэширование — ответы QUERY кэшируемы, при условии что ключ кэша включает само тело запроса.
  3. Ясная семантика — WAF, шлюзы и любые промежуточные слои понимают намерение запроса по самому методу.

Accept-Query

Стандарт добавляет и новый заголовок Accept-Query: сервер объявляет, какие форматы запросов он поддерживает:

Accept-Query: application/jsonpath, application/sql;charset="UTF-8"

Клиент может проверить заранее, вместо того чтобы отправлять наугад и получать 415.

Прежде чем в продакшн

Практика здесь важнее теории:

  • Экосистема ещё догоняет. Многие фреймворки, библиотеки и балансировщики пока не распознают QUERY — часть из них отклоняет запрос до того, как он дойдёт до вашего кода.
  • CORS: метода нет в safelist спецификации fetch, поэтому любой cross-origin QUERY из браузера сначала получает preflight.
  • Кэш — палка о двух концах: нормализация тела на уровне кэша должна совпадать с тем, как сервер интерпретирует запрос, иначе получите ложные попадания в кэш.

Вывод

QUERY — не хайп, а закрытие пробела, существовавшего в HTTP с самого начала. Первые бенефициары — API со сложным поиском и фильтрацией. Разумный путь: начать с внутренних сервисов, где вы контролируете и клиент, и сервер, а POST /search оставить как fallback, пока поддержка не созреет.

Ссылка: RFC 10008 — The HTTP QUERY Method