Как вы строите API на DRF
Вопрос
Расскажите, как вы проектируете эндпоинт на DRF от модели до ответа, чтобы он был безопасным и быстрым.
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Явный список полей сериализатора, read_only для служебных
Валидация в сериализаторе: поля, validate_<field>, validate
`get_queryset` с фильтром по пользователю и select/prefetch_related
Права: IsAuthenticated по умолчанию, объектные проверки
Пагинация, фильтры и сортировка по белому списку
Тесты на права и на число запросов
Что могут спросить следом
- Как запретить менять поле
statusчерез API? - Где хранить логику смены статуса заказа?
Разбор
Образцовый ответ: «Начинаю с контракта: сериализатор с явным списком полей, служебные помечаю read_only, а для разных действий иногда завожу разные сериализаторы, например короткий для списка и подробный для карточки. Проверки делаю в сериализаторе: типы и ограничения полей, validate_<field> для одиночных правил, validate для правил между полями. Во вьюсете главное get_queryset: фильтр по текущему пользователю или организации, чтобы чужие объекты не были доступны даже по id, и select_related/prefetch_related под поля сериализатора. По умолчанию в проекте стоит IsAuthenticated, для объектов свой permission с has_object_permission. Владельца проставляю в perform_create из request.user. Списки всегда с пагинацией, фильтры и сортировка только по разрешённым полям. Бизнес-операции вроде смены статуса выношу в сервис и вызываю из @action. И закрываю тестами: доступ чужого пользователя, анонима и assertNumQueries на список».
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.