Что происходит при отправке запроса с пустым телом

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

Умеете ли вы превращать расплывчатый вопрос в набор конкретных проверок и различаете ли близкие состояния: тела нет вовсе, тело пустая строка, тело {}, тело null. Заодно смотрят, не путаете ли вы ошибку клиента с ошибкой сервера.

Как отвечать

Сначала уточнить метод и контракт, потому что ответ разный. Для GET и DELETE тело не предполагается, и его отсутствие нормально. Для POST, PUT и PATCH пустое тело обычно нарушает контракт.

Дальше перечислить варианты, которые на самом деле являются разными запросами:

• тела нет, заголовок Content-Length: 0;
• тело есть, но это пустая строка;
• валидный JSON без обязательных полей, то есть {};
• тело null или одни пробелы;
• тело есть, а Content-Type не указан либо указан неверно.

Ожидаемое поведение: осмысленный код ответа и понятное сообщение. 400 на неразобранное тело, 422 на разобранный, но не прошедший валидацию объект, 415 на неподходящий Content-Type, 204 там, где операция корректно ничего не возвращает. Плохой признак это 500 со стектрейсом наружу: значит, ввод не проверяется и падает уже внутри.

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

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

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

Второе: считают {} и отсутствие тела одним случаем. Для сервера это разные ветки: в первом JSON разобран и работает валидация схемы, во втором парсер не получил ничего, и ответ часто приходит из совсем другого слоя.

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