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

Модель RoomIn описывала данные, которые клиент присылает в теле запроса. У ответа могут быть другие поля: сервер добавляет идентификатор, а внутреннюю информацию оставляет у себя. Раздельные модели позволяют явно описать оба контракта: что принять и что вернуть.

Входная модель RoomIn и модель ответа RoomOut

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

Решение — два отдельных класса. RoomIn описывает только то, что клиент присылает:

class RoomIn(BaseModel):
    name: str = Field(..., min_length=2, max_length=50)
    capacity: int = Field(..., ge=1, le=50)

RoomOut описывает то, что сервер возвращает. Здесь уже есть id, который добавит обработчик:

class RoomOut(BaseModel):
    id: int
    name: str
    capacity: int

Взаимосвязь простая: RoomIn — контракт запроса, RoomOut — контракт ответа. Поля, которые клиент не присылает, объявляются только в RoomOut. RoomOut описывает публичные поля ответа. Чтобы FastAPI исключал лишние поля из возвращаемого словаря, эту модель нужно подключить к маршруту через response_model=RoomOut; одного объявления класса недостаточно.