FastAPI: DELETE и завершение CRUD для каталога комнат

Удаление комнаты из действующего каталога

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

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

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

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

Что уже дано

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

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

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

Реализуйте DELETE /api/rooms/{room_id}: для существующей комнаты проверьте наличие через get_room_or_404, удалите её из общего rooms_db и верните204 с пустым телом. Успешный DELETE не использует модель тела ответа; response_model=RoomOut несовместим со статусом204. GET и повторный DELETE удалённого id возвращают404/{"detail":"Room not found"}. Отсутствующий id не меняет другие записи. Нечисловой path-параметр даёт стандартный422. Удаление одной комнаты не затрагивает остальные; после него POST продолжает создавать новые карточки с новым серверным id.

Готовый цикл должен оставаться рабочим: POST201 → GET200 → PUT200 → PATCH200 → GET200 → DELETE204 → GET404 → DELETE404. PUT заменяет полный RoomIn с сохранением id, включая сброс пропущенного comment в null. PATCH меняет только name/capacity: пропуск сохраняет поле, {} допустимо, явный null даёт422/{"detail":"Fields cannot be null"} до любых изменений. Адрес и comment этим PATCH не редактируются.

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

Проверяются последовательные запросы в одном процессе; писать клиентский сценарий не нужно. Бронирования, архивирование, база данных, каскадное удаление и сохранность после перезапуска не входят в задачу.

Ввод и вывод

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

Удалите существующую комнату по id из ответа POST: DELETE получает204 без тела. Затем GET по тому же id и повторный DELETE получают404 с {"detail":"Room not found"}. Другая созданная комната остаётся доступной.