Версионирование эндпоинтов — это просто

если уже в начальном описании заметно какой-то бред:

Чтобы создать один order, необходимы customer и product, и в скобках написано (c1, p1), что означает, что вам нужен customer версии v1 и product версии v1, чтобы создать order версии v1. Пока все просто. Но если добавить новые версии, это будет выглядеть вот так:

то дальше нас могут завести в дебри из которых мы вообще не выберемся.

Как известно, версии нужны чтобы клиент мог сравнить интерфейс который он использует с тем который ожидает сервер для обслуживания. Если сервер поддерживает обратную совместимость то версия интерфейса через которую работает клиент может удовлетворять правилу "не выше чем" версия которую поддерживает сервер и его енд-поинты. Таким же образом можно версионировать енд-поинты как наборы интерфейсов, вот это будет просто и понятно.

Тогда нужно каждый новый метод объявлять с version = {X, LATEST_VERSION}, где X - текущее значение LATEST_VERSION, иначе при добавлении новой версии все равно искать где было version = LATEST_VERSION и править

@spring_aioсогласен с первым комментарием и почти нажал "Низкий технический уровень материала". Но даю шанс, потому как тема-то интересная. Я осознаю, что это перевод. и потому продублирую позже мое замечание автору оринигала.

С чем не согласен:

1. Вариантов версионирования вагон и тележка. Я писал про это тут.

2. Нет хороших и плохих вариантов версионирования, есть понимание как это укладывается в общую канву проекта. В статье по ссылке из п.1 я привожу примеры в какой компании какой вариант версионирования используется и почему.

3. Если добавляются варианты версионирования, то это не значит, что предыдущая версия отключается. В таком случае не должно беспокоить, что в какой-то момент клиент перешел на новую версию. И потому фраза "вы должны запустить их точно в один и тот же момент времени" может вызвать только недоумение.

4. В общем, если мы не хотим ничего сломать, то версионирование это просто добавление нового endpoint и добавление его в таблицу роутинга на вебсервере. Есть v2 в headers/url/get вызываем v2-endpoint иначе v1-endpoint. Это довольно дорого по времени программирования, что автор начинает дописывать классы или предлагает править метод диспетчера url а после еще и тесты правит.

В Париже в этом декабре я буду выступать на API-Days, понимаю, что стоит затронуть эту тему еще раз.

>В случае неудачного деплоймента

в каком веке застрял автор? в 21 веке есть blue-green и canary и не существует понятия неудачный деплой