CRUD как HTTP-контракт

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

Содержание курса

GET по id из POST: проверка сохранённой записи

Статус 201 в ответе POST сообщает, что ресурс создан. Но чтобы убедиться, что запись действительно доступна через API, нужно её прочитать — отдельным GET-запросом.

Алгоритм простой: берёте id из тела ответа POST и делаете GET /api/rooms/{id} в том же запущенном процессе.

Например, после POST с телом {"name": "Берлин", "capacity": 8} сервер вернёт:

{"id": 1, "name": "Берлин", "capacity": 8}

Статус — 201. Теперь запрашиваете GET /api/rooms/1 и получаете:

{"id": 1, "name": "Берлин", "capacity": 8}

Статус — 200. Тело совпадает с тем, что вернул POST.

Что делает get_room в коде: он просто читает rooms_db[room_id] и возвращает запись. FastAPI снова применяет RoomOut и отправляет клиенту отфильтрованный ответ.

Если запросить id, которого нет в словаре — например, GET /api/rooms/99 после единственного POST — Python поднимет KeyError, и FastAPI вернёт 500. Обработка отсутствующей записи через HTTPException — отдельная тема следующего урока. Сейчас проверяйте только id из реального ответа POST, не выходя за пределы уже созданных записей.

Данные не переживают перезапуск сервера: после остановки процесса rooms_db очищается, и тот же GET /api/rooms/1 снова вернёт ошибку.

POST /api/rooms с названием Берлин и capacity 8 сохраняет запись rooms_db[1] и возвращает 201. GET /api/rooms/1 читает ту же запись и возвращает 200 с теми же данными.
POST сохраняет «Берлин», 8 мест, и возвращает 201. Последующий GET по полученному id подтверждает доступность той же записи ответом 200 в этом процессе.