Час прошёл. Поехали.

Правильный ответ: А) Бэкенда.

Почему? По шагам. С доказательствами.

Шаг 1. Воспроизвожу

Запрос №1 - пустое тело:

curl -v -X POST https://api.practicum.com/users -H "Content-Type: application/json" -d ''

Ответ: HTTP/1.1 500 Internal Server Error

Запрос №2 - пустой JSON:

curl -v -X POST https://api.practicum.com/users -H "Content-Type: application/json" -d '{}'

Ответ: HTTP/1.1 500 Internal Server Error

Шаг 2. Смотрю в логи сервера

ERROR: NullPointerException at UserController.createUser(UserController.java:42) Cause: 'name' is null

Сервер реально упал. Не обработка - авария. Если бы это был прод, мониторинг бы орал.

Шаг 3. Что говорит RFC?

RFC 7231, раздел 6.5.1:

400 Bad Request - сервер не может обработать запрос из-за невалидных данных.

Пустое тело → невалидный запрос → должен быть 400, а не 500.

500 = «я сломался, но не знаю почему» 400 = «ты прислал фигню, пересылай»

Разница колоссальная. Особенно когда это прод и тимлид смотрит на твой код.

Шаг 4. Как должно быть (код)

def create_user(request): if not request.body: return {"error": "Body is required"}, 400

data = json.loads(request.body) if not data.get("name"): return {"error": "Name is required"}, 400

user = User.create(data) return user.to_json(), 201

Сервер должен: 1. Проверить, что тело есть и оно не пустое 2. Проверить обязательные поля 3. Только потом создавать юзера

Три строки проверки. А они их пропустили.

Шаг 5. Почему вариант «Б» (клиент идиот) - не канает

Клиент может быть любым: 📱 Мобильное приложение с багом 📮 Postman с кривым запросом 👾 Curl из автоматизации 🔁 Другой микросервис

Ты не контролируешь клиента. Никогда.

Сервер - последняя линия защиты. Он должен выживать при любом 💩 на входе.

Если сервер падает на пустом теле - это баг бэкенда. Точка.

Шаг 6. Почему вариант «В» (норма) - тоже мимо

500 = Internal Server Error = «я в панике, всё сломалось».

Если это «нормальная реакция» - значит сервер постоянно в панике. А это: 📉 Uptime падает (мониторинг дёргается по ночам) 🤷‍♂️ Клиент получает непонятную ошибку вместо внятного ответа 😅 Разработчики не понимают, что фиксить

500 - это авария. Для ожидаемых плохих запросов есть 400.

Итог: чек-лист для тестирования POST

Когда тестируешь POST - обязательно проверь:

Сценарий | Ожидаемый статус Тело пустое (no body) ➡️ 400 Тело = {} ➡️ 400 Поле name отсутствует ➡️ 400 Невалидный тип поля ➡️ 400 Всё ок ➡️ 201 Created

🔥 Забрал чек-лист ➕ Узнал новое про 400 vs 500

Хочешь ещё таких разборов с готовыми чек-листами? Practicum уже на подходе, планирую засветить бесплатную версию на следующей неделе 😘