На протяжении шестнадцати лет разработчики, которым нужно было задавать сложные вопросы серверу, были вынуждены использовать обходные пути. Когда полезная нагрузка поиска становилась слишком большой для URL или когда вложенные фильтры и конфиденциальные параметры не помещались в строку запроса, единственным практичным вариантом был POST. Он передавал байты, но лгал о намерениях. POST сигнализирует об изменении состояния. Использование его для операции только для чтения заставляло весь сетевой путь — кэши, прокси-серверы и браузеры — относиться к безобидному поиску так, будто он может изменить базу данных.

Этому компромиссу наконец пришел конец. В июне 2026 года IETF опубликовала RFC 10008, официально стандартизировав метод QUERY. Это первый новый HTTP-метод с момента появления PATCH в 2010 году. QUERY создан специально для безопасных идемпотентных запросов, которым по какой-то причине требуется тело запроса. Он не изменяет состояние сервера. Повторение того же запроса дает тот же результат. Он кэшируемый, а это значит, что промежуточные узлы могут сохранять и повторно использовать ответ. И, в отличие от GET, он позволяет передавать полезную нагрузку, как POST.

GraphQL-запросы и сложные конечные точки поиска REST — главные бенефициары. Вам больше не нужно впихивать шестьдесят параметров запроса в URL или прятать JSON-документ фильтра внутри тела POST-запроса, который промежуточные узлы откажутся кэшировать. Семантика теперь стала честной.

Но RFC — это всего лишь чернила на бумаге. Между вашим приложением и пользователями лежит толстый слой инфраструктуры, и большая часть этой инфраструктуры еще никогда не слышала о QUERY.

Проблема кэширования еще не решена

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

QUERY нарушает эту модель, потому что параметры запроса находятся в теле. Чтобы кэш распознал два идентичных запроса, ключ кэша должен включать в себя и URI, и содержимое тела. Это требование создает реальные операционные сложности.

Во-первых, граничные серверы и CDN должны буферизировать все тело запроса, прежде чем смогут вычислить хеш. Это требует памяти и времени на граничном узле. Во-вторых, два логически идентичных запроса могут выдавать разные байты. Один клиент может отправить {"status":"active"}, а другой — {"status": "active"} с другими пробелами или порядком ключей. Если слой кэширования не будет парсить, нормализовать и канонизировать тело — сортировать ключи JSON, удалять незначительное форматирование и обрабатывать различия в кодировке — один и тот же вопрос будет каждый раз промахиваться мимо кэша.

Что еще более критично, основные CDN пока не разделяют кэш по телу запроса для QUERY. Cloudflare, например, в своей текущей реализации не рассматривает тело как часть ключа кэша для этого метода. Если вы развернете QUERY, полагая, что «кэшируемый» означает «сохраненный в кэше», вы можете столкнуться с ошибками коллизий, повсеместными промахами кэша или ответами, которые «утекают» между несвязанными запросами. Пока ваш провайдер не объявит об явной поддержке, считайте, что QUERY не является значимо кэшируемым в рабочей среде.

Скорее всего, первыми его заблокируют ваши инструменты

Каждый HTTP-запрос проходит через стек промежуточных устройств (middleboxes), и большинство из них применяют строгие правила относительно разрешенных методов.

WAF (Web Application Firewalls) и API-шлюзы часто полагаются на явные белые списки. Типичный набор правил разрешает GET, POST, PUT, DELETE и PATCH. Все остальное отбрасывается или отклоняется с ошибкой 405 Method Not Allowed. QUERY наткнется на эти преграды еще до того, как достигнет кода вашего приложения.

Движки правил безопасности создают еще одно препятствие. Некоторые системы обнаружения вторжений предполагают, что запрос, несущий тело