Comments 5
если уже в начальном описании заметно какой-то бред:
Чтобы создать один
order, необходимыcustomerиproduct, и в скобках написано (c1, p1), что означает, что вам нуженcustomerверсииv1иproductверсииv1, чтобы создатьorderверсииv1. Пока все просто. Но если добавить новые версии, это будет выглядеть вот так:
то дальше нас могут завести в дебри из которых мы вообще не выберемся.
Как известно, версии нужны чтобы клиент мог сравнить интерфейс который он использует с тем который ожидает сервер для обслуживания. Если сервер поддерживает обратную совместимость то версия интерфейса через которую работает клиент может удовлетворять правилу "не выше чем" версия которую поддерживает сервер и его енд-поинты. Таким же образом можно версионировать енд-поинты как наборы интерфейсов, вот это будет просто и понятно.
Тогда нужно каждый новый метод объявлять с version = {X, LATEST_VERSION}, где X - текущее значение LATEST_VERSION, иначе при добавлении новой версии все равно искать где было version = LATEST_VERSION и править
@spring_aioсогласен с первым комментарием и почти нажал "Низкий технический уровень материала". Но даю шанс, потому как тема-то интересная. Я осознаю, что это перевод. и потому продублирую позже мое замечание автору оринигала.
С чем не согласен:
Вариантов версионирования вагон и тележка. Я писал про это тут.
Нет хороших и плохих вариантов версионирования, есть понимание как это укладывается в общую канву проекта. В статье по ссылке из п.1 я привожу примеры в какой компании какой вариант версионирования используется и почему.
Если добавляются варианты версионирования, то это не значит, что предыдущая версия отключается. В таком случае не должно беспокоить, что в какой-то момент клиент перешел на новую версию. И потому фраза "вы должны запустить их точно в один и тот же момент времени" может вызвать только недоумение.
В общем, если мы не хотим ничего сломать, то версионирование это просто добавление нового endpoint и добавление его в таблицу роутинга на вебсервере. Есть v2 в headers/url/get вызываем v2-endpoint иначе v1-endpoint. Это довольно дорого по времени программирования, что автор начинает дописывать классы или предлагает править метод диспетчера url а после еще и тесты правит.
В Париже в этом декабре я буду выступать на API-Days, понимаю, что стоит затронуть эту тему еще раз.
>В случае неудачного деплоймента
в каком веке застрял автор? в 21 веке есть blue-green и canary и не существует понятия неудачный деплой
автор даже не может сформулировать проблему. когда мы контролируем фронт и бэк и можем раскатать любую версию в любую секунду то проблемы нет вообще. проблема возникает когда жизненный цикл потребителя мы НЕ контролируем, например аппки ios/android, когда поставили себе 0.0.1-pre-alpha и упорно не хотят обновляться
Версионирование эндпоинтов — это просто