Срочно обнови телеграм

Теперь в телеге можно задавать вопросы каналу напрямую

И мне пишут про старт в тестировании и подготовку к собеседованию

Самые интересные вопросы буду дублировать в канал регулярно, так что вперёд:

1. Обновить телеграм
2. Нажать на иконку чата в левом нижнем углу экрана
3. Задать Эду классный вопрос
4. Получить крутой ответ 😱

Интересные вопросы приходят.

Пишите, поделюсь мнением, пока меня ИИ не заменил
🥺

⁉️Тело в GET-запросе? ДА!

На каждом втором собесе по тестированию спрашивают:

Можно ли отправить body в GET-запросе?

Правильный ответ: можно, но не стоит
Реальный ответ: это никому не нужно

Почти. Пристегнитесь.
Я тут ТАКОЕ откопал...

Я наткнулся на документацию Elasticsearch — и офигел.

Вот пример оттуда:
GET /my-index-000001/_search
{
"query": {
"match": {
"message": "this is a test"
}
}
}
Тело. В. GET.

И это не случайность — Elastic ОФИЦИАЛЬНО рекомендует делать так.
Почему? 🤔
Потому что Query DSL

Формально — это язык основанный на JSON, специфичный для определённой доменной области, который в этом случае позволяет делать:
🔘сложные фильтры
🔘агрегации
🔘сортировки
всё вместе в одном теле.

Если всё это пихать в URL — не влезет. Поэтому тело.(В ссылку может поместиться ограниченное количество символов и оно разнится в разных браузерах и условиях
https://serpstat.com/blog/how-long-should-be-the-page-url-length-for-seo/#ip4x5j)
Но HTTP против 🤬
По спецификации RFC 7231, §4.3.1]

“A payload within a GET request message has no defined semantics.”

То есть тело можно отправить, но сервер не обязан его учитывать.
Более того, в старом RFC 2616 прямо говорится:
“A message-body MUST NOT be included in a GET request.”

🧱 В ЧЁМ ПРОБЛЕМА
Использовать Elasticsearch вы будете не в вакууме, а на основе своего стека.А фреймворки не в курсе, что можно отправить тело в GET

Express.js
Игнорирует. Тело не парсится.

Spring MVC
@RequestBody не работает. Ошибка.

Django
request.body пуст. Только GET-параметры.

Даже если тело ушло с клиента — оно не дойдёт до бизнес-логики.

🚧 КЕШ И ПРОКСИ
Есть ещё одна ловушка — кеширование.
GET-запросы кешируются по URL. Тело в кеш НЕ ВХОДИТ. Его игнорируют прокси и CDN.
Результат? Запросы с разным телом, но одинаковым URL — будут считаться одинаковыми.
Или наоборот — не кешироваться ВООБЩЕ.
И вы получите нагрузку, задержки и баги.

🤦 ОТЛАДКА
Проверить GET с телом — тот ещё квест.Postman отправит, но может не показать в логах.
curl потребует странного синтаксиса.
Swagger/OpenAPI — вообще не позволяет описать такой запрос.
В OpenAPI 3.0 это считается ОШИБКОЙ.

🧩 А ELASTIC ЭТО ЗАЧЕМ?
Elastic поступает логично: они хотят, чтобы поисковые запросы выглядели как GET, потому что это всё-таки получение данных.И я тут даже задумался, все же логично🌝
Идемпотентность сохраняется, метод безопасен, SAFE

Но даже они признают, что это ненадёжно.

Лучше используйте POST, если в запросе есть тело.

📌 ИТОГ
🔘Если ты тестировщик и на проекте вдруг есть GET с телом — проверяй ВСЕ:проксирование, логи, интеграции
А еще лучше спорь с командой до последнего, чтобы одумалисьИ держи в уме этот факт чтобы блеснуть на собесах 😉
🔘Если ты разработчик и используешь elastic на проекте — держи в голове такие кейсы
🔘Если ты архитектор — не делай так 🙏🥺

Все источники оставил в чате
https://t.me/c/1948889455/839
Отбивай все реакции, шли пост другу и коллеге, чтобы тоже знали.

🧾 Длина URL - это важно

Сколько символов можно уместить в ссылке?
Стандарты говорят: сколько угодно.

> 🧾 “HTTP does not place a pre-defined limit on the length of a URI”
RFC 7230 §3.1.1

> “Interoperability depends on shared expectations of reasonable length”
RFC 7230 §2.7

Реальность: не больше 2-8 тысяч.

📏 Примерные лимиты:

Internet Explorer - 2 083 символа
Источник (Microsoft)

Chrome / Firefox ~32 000 символов
Источник (Sistrix)

Safari - до 80 000 символов
Источник (StackOverflow)

- NGINX - 4 096 байт
Документация

- Apache ~4 000 байт
Документация

- AWS ALB - 8 192 символа
Документация

⚠️ Почему это баг, а не просто “длинно”:

❌ 414 URI Too Long - запрос не прошёл из-за длины строки

❌ 431 Request Header Fields Too Large - когда URL попадает в заголовки (например, в Referer или через раздутые `Cookie`)

❌ 400 или 401 без объяснений - если прокси или ALB просто обрубают запрос

⚔️ DoS-угроза - длинные URL используют для Slow HTTP атак
Рекомендации RaiseUpWA

Что делать?

🔘GET - только для простых фильтров
🔘POST - если параметров больше 5-10 или нужен массив/структура
🔘Не тестируй только в Postman. Там всё работает - а на проде может не дойти.

Подумываю собрать практикум по тестированию API с реальными багами.

- Баги бэкенда, которые встречаются в 90% проектов
- Документация, которая о багах даже не догадывается
- МАКСИМУМ практики — без воды и теории ради теории

Хочешь в первую волну — кидай ➕ в комменты или пиши в личку.
Добавлю на запуске.

Что бесит в API?

Тестирование API: что больше всего путает или вызывает вопросы?

🔘Документация?
🔘Отправка запросов?
🔘Понимание HTTP?
🔘Как писать тест-кейсы и какие?
🔘Как понять: баг или так и должно быть?

Я буквально ради ТВОЕГО ответа могу добавить в практикум нужную именно тебе фичу для тренировки.

Прошлый пост - десятки плюсов, СПАСИБО 🔥
Практикуму БЫТЬ!

Я уже поднял сервак: будет самый реалистичный практикум по тестированию АПИ.

Баги, кривая дока и дотошные тестировщики (вы, то есть❤️)

Так что го в комменты: что хочется видеть в практикуме? ✍🏻

Кстати, под прошлым постом все ещё можно записаться в первый поток, точнее об условиях расскажу позже😎