У бэкенд-разработчиков много лет был довольно неловкий выбор.

Пока фильтров мало, используем GET:

GET /orders?page=2&status=PAID&sort=createdAt,desc

Потом поиск усложняется. Появляются диапазоны дат, группы условий, вложенные фильтры. Query string постепенно превращается в плохо читаемый DSL. Заодно приходится учитывать ограничения на длину URI и то, что адрес запроса может попасть в логи.

Обычно в этот момент появляется такой эндпойнт:

POST /orders/search Content-Type: application/json

{ “status”: [“PAID”, “SHIPPED”], “createdAt”: { “from”: “2026-06-01”, “to”: “2026-06-30” }, “customer”: { “country”: “NL” } }

Решение рабочее. POST вообще не ограничен созданием ресурсов. Сервер может обрабатывать его тело по собственной семантике.

Проблема в другом: на уровне HTTP POST считается потенциально небезопасным и не идмептентным. Прокси, клиенты и другая инфраструктура не знают, что наш /search только читает данные. Такой запрос нельзя автоматически повторять или полноценно кэшировать без дополнительных договоренностей.

Передать тело в GET технически возможно. Но RFC 9110 говорит, что у содержимого GET-запроса нет общепринятой семантики. Некоторые серверы и промежуточные узлы могут отклонить такой запрос. Среди причин упоминаются даже атаки класса request smuggling.

В июне 2026 года IETF опубликовала RFC 10008 с новым методом QUERY:

QUERY /orders HTTP/1.1 Content-Type: application/json Accept: application/json

{ “status”: [“PAID”, “SHIPPED”], “total”: { “min”: 100, “max”: 1000 } }

QUERY предназначен для запросов, описание которых передается в теле. Формат может быть любым, если он обозначен через Content-Type: JSON, SQL, JSONPath или собственный язык фильтрации.

Спецификация закрепляет за QUERY три свойства:

- safe - клиент не запрашивает изменение состояния целевого ресурса - idempotent - запрос можно безопасно повторить - cacheable - ответ разрешено кэшировать

Для кэша есть отдельное правило: ключ должен учитывать тело запроса и связанные с ним метаданные. Поэтому существующие CDN и reverse proxy не начнут кэшировать QUERY сами по себе. Им потребуется поддержка нового метода.

QUERY также умеет работать с conditional requests. А сервер может сообщить о допустимых форматах через новый заголовок Accept-Query.

Что со Spring?

В актуальном Spring Framework полноценной поддержки QUERY пока нет. Проблема находится именно на уровне фреймворка: в RequestMethod отсутствует такое значение, поэтому обычный @RequestMapping нельзя привязать к QUERY.

Обойти ограничение можно через functional endpoints, собственный HandlerMapping или ручную проверку метода. Для нового стандарта это слишком много самодельной инфраструктуры.

Сейчас открыт PR с поддержкой RFC 10008. Команда Spring рассчитывает подготовить ее к Spring Framework 7.1, который ожидается в ноябре 2026 года. Точная версия пока не гарантирована.

Так что переписывать все POST /search сегодня рано. Ждем нормальной поддержки в Spring, клиентах и прокси. Потом уже можно будет с чистой совестью бежать менять поисковые POST-запросы на QUERY.

RFC 10008: https://www.rfc-editor.org/info/rfc10008/

Spring Framework PR: https://github.com/spring-projects/spring-framework/pull/34993