Новый метод в HTTP: дождались-таки
Лето, отпуска, отдых… А ведь кто-то мог и не заметить, что в HTTP появился новый стандартизированный метод.
И это — метод — QUERY
В июне 2026 года опубликован RFC 10008, который стандартизирует этот метод и добавляет его в реестр HTTP-методов IANA.
Почему QUERY был так нужен
Для чтения данных у нас есть GET – простой, кэшируемый, но без тела запроса.
Для записи – POST – с телом, но он считается небезопасным и неидемпотентным.
А что делать, когда нужно отправить сложный поисковый запрос? Например:
- найти билеты на самолёт с пересадками, в конкретном классе, за определённую цену;
- выбрать отели с бассейном, парковкой и завтраком в заданном радиусе;
- получить аналитику по продажам за прошлый год с группировкой по неделям и фильтром по регионам.
Раньше приходилось либо запихивать всё в URL (и получать километровые ссылки, которые режут прокси), либо использовать POST (и терять кэширование и идемпотентность).
Метод QUERY – это безопасный (не меняет состояние) и идемпотентный запрос, который может содержать тело (как POST).
Идеально для сложных выборок, поиска и отчётов.
Как это можно использовать: пример из реальной жизни
Допустим, вы разрабатываете сервис поиска авиабилетов. Раньше GET-запрос выглядел бы страшно:
GET /flights?from=LED&to=JFK&date=2026-09-01&return=2026-09-10&passengers=2&class=business&max_price=1500&stops=0&airlines=SU,AF&sort=price&limit=50
А теперь – чистый, структурированный JSON в теле:
QUERY /flights HTTP/1.1
Host: api.avia.example
Content-Type: application/json
{
"route": {
"origin": "LED",
"destination": "JFK",
"departure_date": "2026-09-01",
"return_date": "2026-09-10"
},
"passengers": 2,
"cabin": "business",
"price_range": { "max": 1500 },
"stops": { "max": 0 },
"airlines": ["SU", "AF"],
"order_by": { "price": "asc" },
"limit": 50
}
Прокси и CDN увидят, что это безопасный запрос, и с удовольствием закэшируют ответ – так же, как они делают с GET. А вы не боитесь, что клиент случайно повторит POST и что-то сломает – QUERY идемпотентен.
Полезные ссылки по теме:
Раз
Два
Лето, отпуска, отдых… А ведь кто-то мог и не заметить, что в HTTP появился новый стандартизированный метод.
И это — метод — QUERY
В июне 2026 года опубликован RFC 10008, который стандартизирует этот метод и добавляет его в реестр HTTP-методов IANA.
Почему QUERY был так нужен
Для чтения данных у нас есть GET – простой, кэшируемый, но без тела запроса.
Для записи – POST – с телом, но он считается небезопасным и неидемпотентным.
А что делать, когда нужно отправить сложный поисковый запрос? Например:
- найти билеты на самолёт с пересадками, в конкретном классе, за определённую цену;
- выбрать отели с бассейном, парковкой и завтраком в заданном радиусе;
- получить аналитику по продажам за прошлый год с группировкой по неделям и фильтром по регионам.
Раньше приходилось либо запихивать всё в URL (и получать километровые ссылки, которые режут прокси), либо использовать POST (и терять кэширование и идемпотентность).
Метод QUERY – это безопасный (не меняет состояние) и идемпотентный запрос, который может содержать тело (как POST).
Идеально для сложных выборок, поиска и отчётов.
Как это можно использовать: пример из реальной жизни
Допустим, вы разрабатываете сервис поиска авиабилетов. Раньше GET-запрос выглядел бы страшно:
GET /flights?from=LED&to=JFK&date=2026-09-01&return=2026-09-10&passengers=2&class=business&max_price=1500&stops=0&airlines=SU,AF&sort=price&limit=50
А теперь – чистый, структурированный JSON в теле:
QUERY /flights HTTP/1.1
Host: api.avia.example
Content-Type: application/json
{
"route": {
"origin": "LED",
"destination": "JFK",
"departure_date": "2026-09-01",
"return_date": "2026-09-10"
},
"passengers": 2,
"cabin": "business",
"price_range": { "max": 1500 },
"stops": { "max": 0 },
"airlines": ["SU", "AF"],
"order_by": { "price": "asc" },
"limit": 50
}
Прокси и CDN увидят, что это безопасный запрос, и с удовольствием закэшируют ответ – так же, как они делают с GET. А вы не боитесь, что клиент случайно повторит POST и что-то сломает – QUERY идемпотентен.
Полезные ссылки по теме:
Раз
Два