сеньорчикОткрыть в Telegram
← все вопросывопросы для собеседований · FastAPI, Django и API

Вопросы по FastAPI, Django и дизайну API на собеседовании

Веб-секция на собесе Python-разработчика редко про синтаксис фреймворка. Спрашивают, чем ASGI отличается от WSGI, как вы версионируете API и что вернёте клиенту, когда запрос пришёл повторно.

211 вопросов в банке·17 подтем·ниже разбор 9

Что спрашивают

Из чего состоит тема

Так тема разложена в тренажёре: движок ведёт прогресс по каждой подтеме отдельно и возвращает те, где вы ошибаетесь.

Разборы подтем

Конспект по каждой: что это, как отвечать вслух, на чём валятся, плюс вопросы для самопроверки.

Примеры вопросов с разбором

  1. #api_versioning1 / 9
    Зачем версионировать публичный API?
    A)Это формальность стандарта, на поведение никак не влияет
    B)Чтобы ускорить ответы новой версии за счёт свежего кэша
    C)Менять контракт, не ломая уже работающих клиентов
    D)Чтобы поисковики лучше индексировали эндпоинты приложения
    показать ответ и разбор
    +C)Менять контракт, не ломая уже работающих клиентов

    // разбор: У публичного API есть внешние клиенты, которых нельзя обновить одномоментно. Версионирование (v1, v2) позволяет вводить несовместимые изменения в новой версии, пока старые клиенты продолжают жить на прежней. Без него любое ломающее изменение кладёт чужие интеграции.

  2. #auth_authz2 / 9
    Пользователь с валидным токеном пытается удалить чужой заказ и получает отказ. Что сработало?
    A)Валидация входа: тело запроса на удаление сформировано неверно
    B)Ограничение частоты запросов, сработавшее на этом клиенте
    C)Авторизация: личность известна, но прав на действие нет
    D)Аутентификация: система не смогла подтвердить его личность вообще
    показать ответ и разбор
    +C)Авторизация: личность известна, но прав на действие нет

    // разбор: Личность подтверждена — токен валиден, аутентификация прошла. Отказ из-за отсутствия прав на чужой ресурс — это авторизация (обычно 403 Forbidden). Аутентификация отвечает «кто ты», авторизация — «что тебе можно»; здесь провалилась именно вторая проверка, а не первая.

  3. #graphql_api3 / 9
    Клиенту нужно 3 поля из объекта, а REST-эндпоинт отдаёт 30. В GraphQL это решается как?
    A)Клиент в запросе перечисляет нужные поля — приходит только они
    B)Сервер заранее заводит по эндпоинту под каждый возможный набор полей
    C)Клиент качает все 30 полей и отбрасывает лишние уже на своей стороне
    D)GraphQL сжимает неиспользуемые поля до нуля байт при передаче по сети автоматически
    показать ответ и разбор
    +A)Клиент в запросе перечисляет нужные поля — приходит только они

    // разбор: В GraphQL клиент описывает в запросе точный набор нужных полей, и сервер возвращает ровно их — это лечит over-fetching (лишние поля) и under-fetching (нехватку, из-за которой в REST делают несколько запросов). Форму ответа определяет клиент, а не фиксированный эндпоинт.

  4. #http_semantics4 / 9
    Что по смыслу делают методы GET, POST, PUT, DELETE?
    A)Читать, создавать, заменять и удалять ресурс
    B)GET изменяет данные, а POST только читает их с сервера
    C)Разница чисто историческая, сервер трактует их одинаково
    D)Все четыре только читают данные, но с разной скоростью ответа
    показать ответ и разбор
    +A)Читать, создавать, заменять и удалять ресурс

    // разбор: GET — безопасное чтение (не меняет состояние), POST — создать/выполнить действие, PUT — заменить ресурс целиком, DELETE — удалить. GET и HEAD «безопасны» (не должны менять данные), что позволяет их кэшировать и повторять без опаски.

  5. #idempotency_grpc5 / 9
    Что значит «идемпотентная операция»?
    A)Операция, требующая ровно одну попытку и запрещающая ретраи
    B)Повтор не меняет результат по сравнению с одним вызовом
    C)Операция, которая выполняется за фиксированное время
    D)Операция, работающая только внутри одной транзакции базы данных
    показать ответ и разбор
    +B)Повтор не меняет результат по сравнению с одним вызовом

    // разбор: Идемпотентность: повторное применение операции с теми же параметрами приводит к тому же итоговому состоянию, что и однократное. Важна для надёжности: при таймаутах и ретраях клиент может послать запрос дважды — идемпотентная операция не создаст дубль и не спишет деньги повторно.

  6. #pagination_filtering6 / 9
    Почему список сущностей нельзя отдавать одним ответом целиком?
    A)Потому что клиент не разберёт большой массив и упадёт на нём
    B)Потому что база данных запрещает возвращать более одной строки без пагинации
    C)На больших объёмах это грузит память и сеть — данные отдают страницами
    D)Потому что JSON технически не способен содержать массив более чем из ста элементов
    показать ответ и разбор
    +C)На больших объёмах это грузит память и сеть — данные отдают страницами

    // разбор: Отдать таблицу из миллионов строк одним ответом — значит выбрать всё из БД, собрать в памяти, сериализовать и прогнать по сети: удар по памяти сервера, задержке и трафику, риск таймаутов. Поэтому большие коллекции отдают страницами фиксированного размера, а клиент запрашивает следующие по мере надобности. Плюс на размер страницы ставят потолок.

  7. #rate_limiting7 / 9
    Зачем API вообще ограничивать частоту запросов (rate limiting)?
    A)Чтобы шифровать трафик и защитить передаваемые данные от перехвата в сети
    B)Защитить от перегрузки и злоупотреблений, честно поделив ресурс
    C)Чтобы клиенты чаще обновляли приложение до последней доступной версии API
    D)Чтобы намеренно замедлить всех пользователей и сэкономить на мощности серверов
    показать ответ и разбор
    +B)Защитить от перегрузки и злоупотреблений, честно поделив ресурс

    // разбор: Rate limiting ограничивает число запросов за окно времени: защищает от перегрузки (случайной лавины, DDoS), пресекает злоупотребления (скрейпинг, перебор паролей), обеспечивает справедливое распределение между клиентами и предсказуемую нагрузку. Превышение лимита сервер отклоняет статусом 429, часто подсказывая, когда повторить.

  8. #rest_design8 / 9
    Как в REST принято выражать ресурс и действие над ним?
    A)Действие кладут в тело POST, а метод оставляют GET
    B)URL — существительное-ресурс, действие — HTTP-метод
    C)Действие указывают query-параметром, а метод не важен вообще
    D)И ресурс, и действие кодируют глаголом прямо внутри пути URL
    показать ответ и разбор
    +B)URL — существительное-ресурс, действие — HTTP-метод

    // разбор: REST моделирует данные как ресурсы: путь — существительное (/users, /users/1), а действие выражает HTTP-метод (GET читать, POST создать, DELETE удалить). Глаголы в пути (/getUsers, /deleteUser) — антипаттерн: они дублируют семантику метода и ломают единообразие.

  9. #validation_serialization9 / 9
    Почему вход API обязательно валидировать на сервере?
    A)Достаточно проверки на клиенте, серверная — лишняя перестраховка
    B)Клиенту доверять нельзя — данные могут быть любыми
    C)Валидация нужна лишь для красивых сообщений об ошибках в UI
    D)Сервер валидирует только ради ускорения последующих запросов
    показать ответ и разбор
    +B)Клиенту доверять нельзя — данные могут быть любыми

    // разбор: Любой клиент (браузер, curl, чужой скрипт) может прислать что угодно в обход UI-проверок, поэтому сервер — единственная надёжная граница доверия: он валидирует типы, диапазоны и инварианты до записи. Клиентская валидация — про UX, серверная — про корректность и безопасность.

это 9 из 211

Ещё 202 вопросов по теме — в тренажёре, с движком повторения

Прочитать разбор и ответить самому — разные навыки. В Сеньорчике вопросы идут сессиями, а движок возвращает подтемы, где вы ошибаетесь, пока они не начнут отскакивать. Бесплатно, лимит по энергии.

Открыть тренажёрДругие темы

Частые вопросы

куда дальше