0: Часто такое бывает, что вы разработали апи. Прошло какое-то время, там полгода, год, полтора, все хорошо работало, но вдруг появились какие-то новые требования, и вам нужно переписать немножко. Апи. Вы поняли, что оно может было неоптимально, что

1: Она выполняла не все функции, но много сервисов уже завязано на ваш апи. Например, тот же самый фронтенд обращается именно к тем эндпоинтам, работает с теми форматами, структурами данных и их отрисовывает клиенту. И обычно.

2: Когда мы говорим о версионировании апи, мы поддерживаем старое апи некоторое время там полгода год, в зависимости от вашего проекта, и в это же время разрабатываем новое api и рекомендуем всем его использовать, например, у меня есть опыт.

3: Использование 1 апи криптобиржи и там около 3 лет. Старая апи ещё работала перед тем, как его полностью снесли. То есть в зависимости от компании, от проекта ваша апи старенькая может существовать там неделю, 2, либо даже несколько лет. Давайте

4: Посмотрим, как работать с версионированием. Есть специальная библиотека, называемая фастапи Веренин. Здесь 500 звёзд, мы пип инсталл, фастапи верженн, прокидываем, конечно, к нам в консоль и здесь это дело запускаем. Пока.

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

6: Да, у нас есть там стартап шатдаун, то их нужно помещать прямо в вот этот класс, с которым мы будем работать. Давайте, собственно, импортируем его, чтобы с ним можно было приятно работать, да, вот.

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

8: Закомментируем и давайте посмотрим на версии. У нас могут быть major и minor версии major. Это когда у нас есть 1, 2, 3 и так далее. Майнер версии это когда у нас есть какой-то, например, 1

9: Точка 0 1, точка 1 и так далее. Мне такой формат не очень нравится. Мне нравится формат конкретно мейджер версии 1, 2, 3 и так далее. Мы будем использовать их. Давайте для примерчика вот этот ввержен. Импортируем из фастапи верженн, например, на бук.

10: Куда-нибудь здесь запихнём, нам нужен, только вержен, и он позволяет таким образом вот таким банальным образом определить версию. Тут 1, тут 1 и, допустим, тут 1. Причём мы

11: Смотрим, что можно указывать не на все эндпоинты, версию и тем не менее все будет работать хорошо. Указали 1 версию здесь сохранили и давайте попробуем сохранить вот это дело, посмотреть, будет ли оно работать. Ювикорн уже запущен, он обновляется и

12: Здесь происходит ошибка, что-то с маунтингом не так, и мы обнаруживаем, что если у нас есть какие-то статик файлы, например, которые мы монтируем, их лучше монтировать уже к конкретно этому приложению, которое мы делаем через version.

13: Api окей, сохраняем, смотрим, что изменилось у нас та же самая ошибка монтирования, и у нас больше нигде нету эп точка маунт у нас только в 1 месте, но если мы работаем с какими-то сторонними библиотеками типа фастапи.

14: Админ или там старлет админ или scale админ. Они скорее всего где-то у себя под капотом используют маунт, поэтому давайте также переместим админку чуть ниже ну или просто вот это чуть выше переместим версионирование и оста.

15: Ставим вот здесь админку и mountain статик файлов давайте посмотрим, что изменилось теперь. Теперь у нас все хорошо работает действительно, потому что mountain мы унесли вниз, давайте посмотрим на наши доки, что с ними, да, как в наших.

16: Доках теперь нету привычных нам эндпоинтов здесь есть только адрес новой документации да в 1 слэш docx в 1 это у нас 1 версия api, и как на него перейти да просто в 1 слэш docx в адресной строке теперь у нас здесь есть.

17: Собственно, 1 наша версия api и здесь есть все эндпоинты, причём, смотрите, мы указали только 3 бронирования, 3 эндпоинта для бронирований, как 1 версию, но все остальные, которые у нас не помечены, эндпоинты, они также перешли в 1 версию. Окей.

18: Приятно. Давайте посмотрим, что если сделать. Например, в букингах добавление Букинга во 2 версию, что произойдёт, сохраняем и посмотрим на доки обратно. У нас теперь появилось 2 версии 1 версия Доков и 2 версия Доков.

19: Соответственно, можно перейти в 1 версию, и здесь мы уже не обнаружим добавление Букинга, но все остальные эндпоинты будут, да, допустим, они, например, не меняются от версии к версии. Ну, такое часто бывает, что у нас часть эндпоинтов нормально работали как в старой версии, так

20: И в новой они оптимально написаны. А вот часть мы нашли, что они как-то плохо там работают, медленно, и мы их переписываем. И вот, например, во 2 версии у нас те же самые эндпоинты остаются, но здесь есть пост booking, а в 1 его нету, да, допустим, какое-то

21: Мы внесли какой-то новый функционал, а если, например, функционал новый мы не внесли, мы просто изменяем старые букинг, то, наверное, имеет смысл, да, 1 пометить как 1 версию, другой пометить как 2 версию и уже

22: Поддерживать их оба, пока не будет дан приказ сносить 1 версию и с ней уже не работать. Таким образом, мы посмотрели на версионирование апи, оно применяется в средних и крупных проектах. Обычно, если вы пишите какой-то свой пед проек,

23: Скорее всего, там не нужно версионирование, но если вам интересно, если вам хочется сделать проект,