🚀 Встречайте новый HTTP-метод — QUERY! Почему QA-инженерам стоит обратить на него внимание?
Если вы вдруг пропустили: в семействе HTTP-методов пополнение. Появился новый метод
HTTP QUERY. Он решает давнюю головную боль проектирования API, с которой сталкивался, пожалуй, каждый тестировщик.В чем была проблема?
Представьте, что вам нужно протестировать эндпоинт поиска со сложной фильтрацией (много параметров, массивы, вложенные объекты).
❌ Использовать
GET? Длина URL ограничена, а передавать Request Body в GET-запросе — плохая практика (серверы и прокси часто его просто игнорируют или отбрасывают).❌ Использовать
POST? Это решает проблему размера, но ломает семантику REST (POST должен изменять состояние) и лишает нас кэширования, которое есть у GET.Что меняет HTTP QUERY?
Он работает как
GET (является безопасным, идемпотентным и поддерживает кэширование), но при этом официально поддерживает тело запроса (Payload / Request Body)! Теперь сложные фильтры, GraphQL-запросы и тяжелые поисковые параметры можно передавать по стандарту.🔍 Что это значит для нас, тестировщиков (QA):
1️⃣ Новые тест-кейсы на кэширование: В отличие от поисковых POST-запросов, ответы на QUERY могут и должны кэшироваться. Это нужно будет проверять отдельно.
2️⃣ Проверка тулинга: Придется убедиться, что ваши любимые инструменты (Postman, Swagger, Charles, фреймворки вроде RestAssured или Playwright) корректно переваривают новый метод.
3️⃣ Секьюрность и логирование: Параметры из URL всегда попадали в логи веб-серверов. Тело запроса (Body) часто не логируется по умолчанию. Стоит проверять, как логируются новые QUERY-запросы и не скрывается ли там что-то важное для дебага.
🔗 HTTP QUERY: Why QA Engineers Should Care About the New HTTP Method
💬 Уже слышали про метод QUERY? Как думаете, как быстро этот метод станет стандартом в индустрии? Делитесь мыслями в комментариях! 👇
