Вперше за 16 років протокол HTTP офіційно отримав новий метод — QUERY. Він вирішує одну з найстаріших архітектурних проблем веб-розробки: як правильно і семантично передавати складні параметри для читання даних.
Проблема: Складні фільтри в GET-запитах
Традиційно для отримання даних використовується метод GET. Проте GET-запити мають суттєве обмеження — вони не розраховані на передачу тіла запиту (body). Усі параметри доводиться передавати через рядок запиту (Query String) в URL.
Уявіть ситуацію: вам потрібно відфільтрувати список користувачів за десятком критеріїв, серед яких вкладені умови, масиви статусів та сортування. Ваш URL швидко перетворюється на щось подібне:
GET /api/users?age_min=18&age_max=35&status[]=active&status[]=pending&role=manager&last_login_after=2025-01-01T00:00:00Z&sort=-created_at&include=profile,company&search=developer
Якщо логіка стає ще складнішою (наприклад, з'являються умови OR чи фільтрація за координатами), генерувати, парсити та читати такий URL стає неможливо. Більше того, більшість серверів та проксі мають жорсткі ліміти на довжину URL (зазвичай від 2 до 8 KB). Якщо ви перевищите цей ліміт, сервер поверне помилку 414 URI Too Long.
POST як тимчасове рішення
Щоб обійти ці ліміти і передати параметри у вигляді зручного JSON, розробники масово почали використовувати метод POST для read-запитів. Саме на цьому побудований GraphQL та ElasticSearch.
Але використання POST для читання ламає семантику HTTP. Метод POST призначений для зміни стану сервера. Він не є безпечним (safe) та не є ідемпотентним. Через це стандартні механізми кешування (CDN, браузери, проксі) відмовляються кешувати такі відповіді, адже вважають, що запит міг змінити дані на сервері.
Рішення: Метод QUERY
Метод QUERY поєднує переваги обох підходів. За стандартом він є безпечним та ідемпотентним (як GET), але при цьому офіційно дозволяє передавати дані в тілі запиту (як POST).
Тепер той самий складний запит виглядає так:
QUERY /api/users
Content-Type: application/json
Accept: application/json
{
"filters": {
"age": { "min": 18, "max": 35 },
"status": ["active", "pending"],
"role": "manager",
"last_login_after": "2025-01-01T00:00:00Z",
"search": "developer"
},
"sort": "-created_at",
"include": ["profile", "company"]
}
Головна перевага полягає в тому, що інфраструктура зможе кешувати такі запити. Ключем для кешу слугуватиме комбінація URL та хешу тіла запиту.
Чи можна використовувати це вже зараз?
Стандарт RFC 10008 затверджено, проте екосистема ще потребує часу на адаптацію:
Балансувальники навантаження, WAF та CDN повинні навчитися не блокувати новий метод і правильно будувати ключі кешування.
HTTP-клієнти (включно з браузерним fetch) потребують оновлень для коректної обробки QUERY.
Бекенд-фреймворки мають додати вбудовані методи маршрутизації (наразі нативна підтримка з'являється лише в найновіших версіях платформ, таких як .NET 10).
На даному етапі QUERY чудово підходить для внутрішньої комунікації між мікросервісами, де ви повністю контролюєте інфраструктуру. Для публічних API та роботи з веб-клієнтами метод POST ще деякий час залишатиметься стандартом де-факто.