Давайте поговорим о том, как мы можем представить прогноз погоды и все движущиеся части
в нашем API. Поэтому мы начали с использования нашего существующего местоположения pydantic
модель, где она уже прошла валидацию.
Город необходим. Остальные вещи либо необязательны, либо необязательны с настройками по умолчанию.
И часть того, что они представляют, часть отчета-это место, где они находятся.
это ведь случилось, верно? Также,
нам нужна дополнительная информация вместе с этим местоположением.
Что там произошло? Поэтому вместо того, чтобы просто брать местоположение и описание отдельно,
мы действительно могли бы пройти через pydantic и сказать
мы собираемся создать класс отправки отчетов,
и у него есть местоположение, и pydantic фактически выполнит эту иерархическую привязку путем обхода
вещь, которая была представлена, находя свое местоположение,
затем привязка этого к определенному местоположению
объект и так далее. Красивый.
Это не последнее, что мы хотели сохранить или отправить обратно.
Но это то, что мы приняли от пользователя.
Помню, у нас был класс доклады, которые вытекают из представления доклада. Здесь,
мы используем именно то место, которое находим выше, и pydantic связывает это вместе.
И наконец, у нас просто есть наш асинхронный отчет, или мы его дали
имя. Здесь это просто отчеты.
Может быть, добавить отчет, что-то в этом роде.
Это требует представления отчетов и здесь это не задокументировано,
но add Report возвращает правильный отчет
объект. Вот и все. Это все, что нам нужно сделать.,
и он очень чистый. Pydantic справляется с такой большой его частью.
Помните также, что тестировать конечные точки post API не так просто
как и для того, чтобы проверить get ones в вашем браузере.
Поэтому вы должны посмотреть на что-то вроде почтальона или какого-то другого инструмента, который позволит вам
очень тщательно контролируйте то, что отправляется в ваш API, и тестируйте его.