Модели создания и ответа

Публичная карточка Roomly

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

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

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

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

Что уже дано

Дан самостоятельный файл с app, готовыми Address и RoomIn, а также обработчиком POST /api/rooms. Входная валидация уже работает. Обработчик задаёт демонстрационный id=101 и возвращает словарь, содержащий служебное internal_note. Сейчас оно попадает к клиенту. Дополните файл моделью ответа и подключите её к существующему маршруту; второй маршрут на тот же путь не добавляйте.

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

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

Объявите RoomOut на основе BaseModel и подключите её через response_model. Публичный ответ со статусом 200 должен содержать ровно id, name, capacity, вложенный address с city и street, а также comment — строку или null. Обязательные поля RoomOut: id, name, capacity, address; для comment допустим None по умолчанию. Поля internal_note в публичной модели быть не должно.

Сохраните входной контракт RoomIn: обязательное имя длиной 2–50 символов, обязательная вместимость 1–50, обязательный вложенный адрес с двумя строками и необязательный комментарий. Входные ошибки остаются стандартными 422, включая путь к неверному вложенному полю. Клиентский лишний id не должен подменять серверный: результат всегда содержит демонстрационное число 101.

Служебная пометка остаётся в возвращаемом обработчиком словаре; настройте исключение поля через модель ответа. Данные не сохраняются, счётчик не нужен: число 101 не обещает уникальность и не означает создание комнаты.

Ввод и вывод

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

POST /api/rooms с {"name": "Вяз", "capacity": 8, "address": {"city": "Омск", "street": "Садовая"}} получает 200 и {"id": 101, "name": "Вяз", "capacity": 8, "address": {"city": "Омск", "street": "Садовая"}, "comment": null}. Служебной пометки в ответе нет.