Что такое пейлоады и как с ними работать

Что проверяют

Понимаете ли вы, где заканчивается транспорт и начинаются данные, и умеете ли аккуратно формировать, валидировать и логировать тело запроса. Вопрос базовый, поэтому ценится точность формулировок и знание практических деталей клиента.

Как отвечать

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

r = httpx.post(url, json=payload, timeout=5)
r.raise_for_status()
data = r.json()

Важная деталь, которую спрашивают: передача через параметр json сериализует объект и сама выставляет тип содержимого application/json, передача через data отправляет форму, а передача готовых байтов ничего не выставляет. Заголовок должен соответствовать телу, иначе сервер ответит отказом по типу содержимого.

На приёме тело не считается доверенным: валидация схемой (pydantic или явная проверка), ограничение размера, понятный ответ с кодом ошибки валидации вместо пятисотки. Полезно упомянуть, что у GET тела по спецификации нет, что при повторе запроса нужна идемпотентность, а крупные файлы передаются потоком или составным запросом, а не полем с двоичными данными внутри JSON.

Где спотыкаются

Путают тело с параметрами адреса и с заголовками. Складывают фильтры в тело GET, а секреты в строку запроса, где те оседают в журналах прокси и в истории браузера.

Логируют пейлоад целиком. В теле обычно лежат токены, персональные данные и платёжные реквизиты, и такой журнал превращается в утечку. Нужен список полей под маскирование и обрезка по размеру.

Разбирают входящее тело обращением по ключам без проверки и падают на первом неожиданном запросе, а на исходящих вызовах забывают таймаут и ограничение размера ответа. Отдельная классика это тесты, которые ходят в настоящий внешний адрес: они падают не там, где ошибка, а там, где сеть.