Отсутствующий ресурс и HTTPException

Карточка по неверному идентификатору

Roomly — внутренний сервис, который хранит карточки переговорных комнат и выдаёт их по запросу. Сотрудник, желающий узнать сведения о конкретной переговорной, передаёт её идентификатор и ожидает в ответ либо готовую карточку, либо однозначное сообщение о том, что такой комнаты в каталоге нет.

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

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

Что уже дано

Это самостоятельный файл main.py для браузерного редактора: код ваших прежних решений не переносится автоматически. Модели Address, RoomIn, RoomOut, верхнеуровневый app, пустой rooms_db и начальный next_id уже в файле. Это отдельное упражнение на полную карточку из урока11, а не объединение всех прежних каталогов и фильтров. POST уже создаёт записи с201. GET вызывает незавершённую функцию get_room_or_404; именно её нужно дополнить.

Служебный переходник выполняется перед файлом, но не создаёт app или данные. Он только передаёт запросы и результаты между приложением и скрытой проверкой; менять его не нужно.

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

Реализуйте публичную функцию get_room_or_404(room_id: int) -> dict: она возвращает словарь найденной записи, а для отсутствующего целочисленного id поднимает HTTPException со статусом404 и detail="Room not found". Проверка наличия не создаёт записей и не изменяет каталог. Готовый GET должен по-прежнему получать результат через эту функцию.

GET /api/rooms/{room_id} возвращает200 с полной публичной карточкой существующей комнаты или404 с {"detail":"Room not found"}. Нечисловой path-параметр сохраняет стандартный422. POST продолжает создавать новые записи с201; поиск отсутствующего ресурса не должен мешать дальнейшему добавлению.

Готовая RoomIn принимает обязательные name (строка длиной2–50), capacity (целое1–50) и address (объект с обязательными строками city, street). comment — необязательная строка или null, default — None. Сохраните эту валидацию: неверное тело получает стандартный422, включая путь вложенного поля. Публичная карточка содержит ровно id, name, capacity, address, comment; internal_note наружу не попадает. Лишние входные поля игнорируются; клиентские id и internal_note не подменяют серверные данные.

Работа идёт последовательно в одном запуске. PUT/PATCH/DELETE, Depends и база данных не нужны.

Ввод и вывод

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

В пустом каталоге GET /api/rooms/99 получает404 и {"detail":"Room not found"}. После успешного POST запросите id из его ответа: GET вернёт200 с созданной карточкой.