Зависимости через Depends

Просмотр каталога небольшими частями

Офис-менеджер в Roomly работает с каталогом переговорных комнат ежедневно: уточняет названия, проверяет описания, сверяет детали. Каталог может быть достаточно длинным, и просматривать его целиком за один раз неудобно — гораздо естественнее двигаться по нему небольшими частями, останавливаясь ровно там, где нужно.

Для этого менеджер указывает, с какого места в списке начать и сколько комнат показать за один раз. Если никаких уточнений не задано, просмотр начинается с самого начала в привычном порядке. Этот порядок остаётся одинаковым от запроса к запросу, а сам каталог при чтении, разумеется, не изменяется.

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

Программа должна корректно обслуживать оба сценария, сохраняя их независимость и возвращая именно те данные, которые менеджер запросил.

Что уже дано

Видимый файл — самостоятельное упражнение только на чтение, как pagination_demo из урока; оно не заменяет CRUD-проект. Даны app, router, полные Address/RoomOut, словарь rooms_db с тремя карточками и рабочая функция get_room_or_404. Поиск переписывать не нужно. Начальный каталог имеет id1,2,3; проверка может заменить rooms_db другим каталогом той же формы, включая пустой, чтобы проверить повторное чтение. Порядок записей — порядок вставки, не сортировка по id или имени.

Служебный переходник не создаёт приложение или модели. Он передаёт HTTP-запросы, может заменить входной rooms_db и вызвать get_pagination с обычными аргументами. Отдельно он передаёт безопасные метаданные регистрации Depends и диагностически подставляет результат зависимости, чтобы проверить его использование обработчиком. HTTP-запросы проверяют ответы и источник параметров. Писать переходник, подстановки или тесты не нужно.

Что нужно сделать

Реализуйте публичную функцию get_pagination(skip: int = 0, limit: int = 10) -> dict, возвращающую параметры под ключами skip и limit. GET /api/rooms должен получать этот словарь через Depends и возвращать соответствующую часть текущего каталога: пропустить skip записей и взять не более limit. Область задания — неотрицательные целые, в том числе limit=0 и skip за концом. Если query отсутствует, используются defaults функции; неконвертируемое значение даёт стандартный422 с loc query/skip или query/limit. Дополнительную политику для отрицательных значений вводить не нужно.

GET /api/rooms/{room_id} получает найденную запись через Depends от готового get_room_or_404. Источник room_id — путь, одноимённый query его не заменяет. Существующая комната даёт200, отсутствующая —404 с detail="Room not found", неверный тип path — стандартный422 с loc path/room_id. Чтение не изменяет каталог.

Оба маршрута возвращают полные публичные карточки: ровно id, name, capacity, address с city/street, comment. Служебные поля наружу не попадают. Подключите результаты обеих зависимостей как параметры обработчиков; одного ручного вызова или регистрации неиспользуемой зависимости недостаточно. Имена обработчиков и их параметров выбирайте сами.

Ввод и вывод

stdin не используется. Печатать через print в stdout ничего не нужно. После выполнения файла проверяющая система обращается к верхнеуровневому app: публичный переходник вызывает TestClient внутри процесса приложения и передаёт результат скрытой проверке. Запускать Uvicorn, сеть, клиентский скрипт или pytest не требуется.

Для начального каталога GET /api/rooms?skip=1&limit=1 возвращает список только с карточкой Бета (id2). GET /api/rooms/1?room_id=99 по-прежнему возвращает Альфу (id1).