Модель описывает принимаемые данные
В FastAPI тело запроса можно объявить через модель Pydantic. Поля модели задают ожидаемые типы и дополнительные ограничения. Например, количество мест должно быть целым числом, большим нуля. Требование положительности нужно выразить отдельно: обозначение типа int само по себе не запрещает отрицательные значения. Полезно заранее решить, допускается ли преобразование входных значений. Pydantic по умолчанию в некоторых случаях преобразует данные к нужному типу: строковая запись числа может стать целым числом. Если для конкретного поля важно принимать именно целое значение без такого преобразования, используют соответствующий строгий режим. Его поведение следует проверять для выбранного типа, а не переносить одно правило на любые данные.
Ограничение поля не знает состояния всего сервиса
Положительное количество три соответствует простому правилу модели, но не доказывает, что осталось три свободных места. Доступность зависит от текущих данных сервиса. Даже если места были свободны минуту назад, другой запрос мог изменить ситуацию. Значит, проверка структуры является только одним этапом. Далее приложение применяет предметные правила: существует ли нужное событие, открыта ли запись, достаточно ли мест. Реальное оформление бронирования также должно учитывать одновременные запросы. Одна предварительная проверка наличия мест не гарантирует отсутствие перепродажи, если проверка и изменение состояния не согласованы на уровне хранения данных.
Право пользователя проверяют отдельно
Корректный идентификатор чужого бронирования остаётся корректным идентификатором. Тип числа ничего не сообщает о том, вправе ли текущий пользователь отменять именно эту запись. Для решения требуется установить пользователя и применить правила доступа к конкретному объекту и действию. Не следует доверять только присланному полю владельца: клиент может указать другое значение. Источник сведений о текущем пользователе и проверка его полномочий относятся к серверной логике безопасности. Понятное разделение проверок помогает и при тестировании. Одни случаи проверяют неверную форму данных, другие допустимые данные при нарушении предметного правила, третьи попытку выполнить чужое действие. Успех одной группы не заменяет проверку остальных.
Попробуйте на практике
Спроектируйте проверки вымышленного запроса на бумаге. Не запускайте сервер и не обращайтесь к чужим данным.
- Задайте учебное правило: количество мест принимается строгим целым числом больше нуля; изменение бронирования доступно только его владельцу. Свободных мест в примере два.
- Разберите четыре входа: целое число один, целое число минус два, строковую запись единицы и целое число три. Отдельно определите соответствие типу, положительности и наличию мест.
- Для допустимого количества один добавьте два случая: запрос владельца и запрос другого пользователя. Объясните, почему одинаковое тело запроса не означает одинаковое разрешение.
- Запишите, какие сведения предоставляет клиент, а какие сервер должен установить самостоятельно. Добавьте необходимость учитывать одновременное изменение количества мест.
Как проверить результат. Единица проходит проверки количества; минус два нарушает положительность; строка не проходит выбранное строгое правило; тройке не хватает мест. Право изменить запись проверяется отдельно для текущего пользователя.
Частые вопросы
Нужно ли делать все поля строгими?
Это решение контракта приложения. Преобразование бывает удобным и ожидаемым, но его необходимо понимать и проверять, особенно на границах типов.
Заменяет ли автоматически созданная схема проверку безопасности?
Нет. Схема помогает описать данные, но не доказывает правильность установления пользователя, проверки доступа и согласованного изменения состояния.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.