Какой HTTP метод используется для создания сущности

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

Базовое знание REST и то, как вы воплощаете его в своём фреймворке. Вопрос простой, поэтому следом почти всегда идут уточнения: чем POST отличается от PUT, какой статус вернуть и что будет при повторном запросе.

Как отвечать

Сущность создаётся запросом POST на коллекцию: POST /users с данными в теле. Сервер назначает id и отвечает 201 Created, в теле созданный объект, в заголовке Location его адрес. Дальше три тезиса:

• POST не идемпотентен: повтор создаст вторую запись. Защита: уникальные ограничения в базе и ключ идемпотентности от клиента;
• PUT тоже может создавать: PUT /users/{id} создаёт ресурс по адресу, который знает клиент, и при этом идемпотентен. Подходит, когда id генерирует клиент, например UUID;
• PATCH: меняет часть полей существующей сущности, тогда как PUT заменяет её целиком.

Покажите, как это выглядит в вашем фреймворке, на этом и видна разница между кандидатами:

• FastAPI: @app.post("/users", status_code=201). Без явного status_code FastAPI отдаст 200. Ошибки валидации Pydantic по умолчанию превращаются в 422;
• Django REST Framework: ModelViewSet и CreateAPIView через CreateModelMixin уже возвращают 201, ошибки сериализатора дают 400;
• Flask: статус задают руками, return jsonify(user), 201.

Если спросят про клиентскую сторону: requests.post(url, json=data, timeout=5). Параметр json сам сериализует тело и выставит Content-Type: application/json, а таймаут стоит указывать всегда, по умолчанию requests ждёт ответа бесконечно.

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

Отвечают «POST» и останавливаются. Интервьюер ждёт хотя бы статус 201 и пару слов про идемпотентность.

Забывают status_code=201 в FastAPI и считают, что фреймворк сам поймёт, что это создание. API отдаёт 200, и клиенты, которые проверяют именно 201, ломаются.

Шлют данные через data= вместо json= в requests. Тело уходит как форма, сервер ждёт JSON и отвечает 422 или 400.