Создание ресурса: POST и статус 201

Переговорные остаются в каталоге

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

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

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

Что уже дано

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

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

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

Доработайте POST /api/rooms: корректное описание создаёт отдельную запись, получает новый серверный целочисленный id и ответ201. GET по выданному id возвращает200 с той же полной карточкой. Несколько последовательных POST сохраняют все прежние записи, в том числе когда описания двух комнат совпадают: это два добавления, а не замена. Имена обработчиков выбирайте сами.

Готовая 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 не подменяют серверные данные.

Проверяются последовательные запросы в одном запуске. Сохранение после перезапуска не требуется. В этом уроке GET вызывается только для уже созданных id; обработка отсутствующей записи, PUT/PATCH/DELETE не нужны.

Ввод и вывод

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

POST /api/rooms с {"name":"Липа","capacity":4,"address":{"city":"Омск","street":"Мира"}} создаёт карточку и возвращает201. Если получен id=1, GET /api/rooms/1 вернёт200 и {"id":1,"name":"Липа","capacity":4,"address":{"city":"Омск","street":"Мира"},"comment":null}.