👉 Новый стандарт 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