Геннадий Чурсов | QA++ on Telegram: “Как не завалить собеседование на HTTP-методах в…”

Как не завалить собеседование на HTTP-методах в 2026 году? 🤔

Теперь когда вас спросят назвать HTTP-методы, не ограничивайтесь привычным набором GET, POST, PUT, PATCH, DELETE. С июня появился ещё один стандартизированный метод: QUERY.

Это не замена GET. Это отдельный способ сказать серверу: «выполни сложный запрос, но ничего в данных не меняй».

Какую проблему он решает и почему его так давно хотели?

Представьте endpoint аналитики.
С GET он быстро становится таким:

GET /analytics/events?from=2026-06-01&to=2026-06-30&groupBy=country&groupBy=platform&event=checkout_completed&includeInactive=false HTTP/1.1

Пока параметров пять — терпимо.
Когда появляется десяток фильтров, массивы, диапазоны, сортировки и правила агрегации — URL превращается в строку, которую никто не хочет ни читать, ни дебажить.

Исторически в такой ситуации делают так:

POST /analytics/events/search HTTP/1.1
Content-Type: application/json

{
  "period": {
    "from": "2026-06-01",
    "to": "2026-06-30"
  },
  "filters": {
    "event": "checkout_completed",
    "includeInactive": false
  },
  "groupBy": ["country", "platform"]
}

Работает. Но для инфраструктуры POST означает: «осторожно, тут теоретически могут быть изменения». После сетевого сбоя клиент не должен бездумно повторять такой запрос: вдруг сервер уже успел создать заказ, списать деньги или запустить джобу.

С QUERY тот же вызов выглядит так:

QUERY /analytics/events HTTP/1.1
Content-Type: application/json

{
  "period": {
    "from": "2026-06-01",
    "to": "2026-06-30"
  },
  "filters": {
    "event": "checkout_completed",
    "includeInactive": false
  },
  "groupBy": ["country", "platform"]
}

И его семантика уже понятна на уровне протокола:
— запрос безопасный: клиент не ожидает изменения состояния ресурса;
— идемпотентный: при обрыве соединения его можно повторить;
— тело запроса — нормальная часть контракта, а не спорный GET с body;
— ответ можно кешировать, хотя кешу придётся учитывать ещё и содержимое body.

Где это может пригодиться?
Поиск по каталогу, отчёты, сложная фильтрация, построение выборок, аналитические API, внутренние платформенные сервисы.

Почитать поподробнее: https://www.rfc-editor.org/rfc/rfc10008.html

Сохраняй пост, чтобы перед следующем собеседованием повторить: помимо привычных HTTP-методов теперь есть ещё QUERY для сложных read-only запросов с body.