❗️ Новый HTTP-метод QUERY: значительное изменение стандарта впервые за 16 лет ❗️


👉 Новый стандарт RFC 10008 от 15 июня 2026
https://www.rfc-editor.org/info/rfc10008/
добавил новый HTTP-метод "QUERY".

Он закрывает боль, с которой аналитики и разработчики встречаются каждый раз, когда проектируют работу со списками и поиском, где нужно:
+ много фильтров,
+ сортировки,
+ пагинация.


👉 Назначение QUERY:
поиск по каталогу с десятком фильтров.

Например:
▫️ категория
▫️ цена
▫️ город
▫️ даты
▫️ сортировка
▫️ пагинация
▫️ другие



👉 Вопрос собеседования:

Как сделать запрос на получение данных с кучей фильтров?

Старые ответы:

❌ GET с фильтрами в URL

GET /products?city=spb&priceFrom=1000&priceTo=5000&sort=rating...

Логика правильная:
+ GET - про получение данных.
+ мы ничего не создаём, ничего не меняем, просто читаем данные.

Но у GET есть проблема.
Если фильтров много:
▫️ URL становится огромным
▫️ прокси, браузеры и балансировщики могут резать длинные адреса
▫️ сложные JSON-фильтры неудобно кодировать в строку
▫️ параметры запроса засоряют логи

Для простого поиска GET подходит.
Для сложного поиска — уже нет.

Пример GET


❌ POST с фильтрами в теле запроса.
Можно красиво передать фильтр в JSON:

POST /products/search

{
  "city": "spb",
  "priceFrom": 1000,
  "priceTo": 5000,
  "categories": ["hotel", "apartment"],
  "sort": "rating,asc"
}

Но появляются другие проблемы:
▫️ нецелевое использование: POST - предназначен для создания данных, а не для чтения
▫️ он не идемпотентный: при повторном вызове ожидаются изменения
▫️ его сложнее кэшировать

Пример POST


Новый ответ:

✅ QUERY с фильтрами в теле запроса

Он забирает лучшее у двух подходов:

🟢 От POST он берёт тело запроса

То есть сложный фильтр можно передать в JSON:

QUERY /products/search
Content-Type: application/json

{
  "city": "spb",
  "priceFrom": 1000,
  "priceTo": 5000,
  "categories": ["hotel", "apartment"],
  "sort": "rating, asc"
}

🟢 А по смыслу QUERY ближе к GET
Он говорит серверу и всей инфраструктуре по пути: этот запрос только читает данные и не меняет состояние ресурса.



Из этого следуют два важных свойства:

👍 1. QUERY можно безопасно повторять
Если сеть оборвалась, клиент может повторить запрос.
Метод заявлен как идемпотентный.


👍 2. Ответ на QUERY можно кэшировать
Но не просто по URL.
Ключ кэша должен учитывать:
▫️ адрес запроса
▫️ тело запроса
▫️ связанные метаданные

То есть:
один и тот же URL + один и тот же фильтр = можно вернуть готовый ответ из кэша.

А другой фильтр в body = другой результат и другой ключ кэша.

Это особенно полезно для тяжёлых поисковых запросов, каталогов и аналитических выборок.



❗️ Актуальные проблемы 2026 для HTTP QUERY

Хотя QUERY уже есть в стандарте HTTP, экосистема ещё догоняет.

Проблемы:

▫️ сервер или фреймворк пока не понимает такой метод
▫️ API Gateway может не пропустить незнакомый тип запроса
▫️ CDN может ещё не уметь нормально кэшировать такие ответы
▫️ генераторы документации не знают этот метод (в том числе OPEN API)
▫️ в Postman и других инструментах тестирования QUERY пока не добавлен
▫️ SDK не поддерживают этот метод
▫️ в браузере могут появиться дополнительные проверки перед запросом

Поэтому пока с внедрением QUERY лучше не торопиться.


👉 Как внедрять:

▫️ для внутренних API (обмен данными между микросервисами, для ваших веб- и мобильных приложений) — можно начинать использовать.

▫️ для публичных API (подключение к вам партнеров, интеграции с внешними систами) — лучше пока подождать.

Перед внедрением обязательно проверьте поддержку в стеке разработки, документации, клиентах, шлюзах, кэшах и инструментах мониторинга.



Так что теперь в HTTP:
👉 GET, POST, PUT, PATCH, DELETE, QUERY
OPTIONS, HEAD, TRACE, CONNECT


👉 Запомните логику:
▫️ простой поиск — GET
▫️ создание — POST
▫️ сложный поиск с body — QUERY


Стандарт появился.
Теперь ждём, когда инструменты и инфраструктура массово обновятся.


❤️‍🔥 Подписывайтесь на GetAnalyst, чтобы быть в курсе актуальных обновлений IT, важных для аналитиков


#ИнтеграцииGA #RestApiGA