Что будет если отправить запрос с пустым JSON объектом

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

Умеете ли вы думать про границы входных данных и отличаете ли пустой объект от пустого тела и от null. Это проверка на тест-дизайн, а не на знание протокола: смотрят, назовёте ли вы ожидаемый результат до того, как полезете смотреть, что реально вернёт сервер.

Как отвечать

Начните с того, что ответ задаётся контрактом, и сформулируйте ожидание. Для POST с обязательными полями правильный результат это 400 или 422 с машиночитаемым описанием, каких полей не хватает. Для PATCH пустой объект обычно валиден и означает запрос без изменений: 200 или 204, ресурс остаётся прежним. Для PUT, который заменяет ресурс целиком, пустой объект либо отвергается, либо обнуляет поля, и это уточняется по документации, а не угадывается.

Дальше разложите соседние случаи, ради них вопрос и задают:

• {} против полностью пустого тела и против тела null;
• отсутствующий или неверный Content-Type;
• невалидный JSON вроде одной открывающей скобки, тут ждём 400, а не 500;
• поля присутствуют, но со значениями null или пустыми строками, это уже другой класс проверок.

Закончите тем, что проверяете не только код ответа: тело ошибки, отсутствие следов запроса в базе, запись в лог без утечки трассировки наружу, и что повторная отправка ведёт себя так же.

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

Отвечают «вернётся ошибка» и останавливаются. Ценность ответа в конкретике: какой код, какое тело, что при этом происходит с данными на сервере.

Второе: не проверяют побочные эффекты. Сервер может вернуть 400 и всё равно создать пустую запись или списать попытку из лимита, и такие дефекты находятся только осмотром состояния после запроса.

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