А если это минорная версия конкретного эндпоинта, а не мажорная всего API? Я придерживаюсь подхода установки версии после /api в случаях с мажорными апдейтами всего сервиса. В Вашем случае при мажорном переезде всего API версия /api/v1 может быть занята у эндпоинта в котором Вы делали минорный фикс. И что, в этом случае у Вас будет /api/v2 для одного эндпоинта вместо /api/v1 для всех?
Не согласен с частотой изменения этих версий. В мобильном деве приходилось иметь вплоть до 2-3 версий (из-за необходимости поддерживать эндпоинты для старых версий приложения) и это было далеко не крупное приложение.
При любом подходе придется чем-то жертвовать, и причем всегда финансово) Либо тратить деньги на разработку и поддержку кода, либо тратить деньги на поддержку серверов со старыми версиями)
Почему сломалась? Сейчас проверил - все окей. Ну а чтобы совладать с миграционным адом - поддерживать сервера с разными версиями, как было написано в начале статьи:
может себе позволить содержать сервера с разными версиями серверного приложения (api.host.v1, api.host.v2) и умеет их грамотно поддерживать
В этом случае не нужно поддерживать большинство старого кода. Нужно просто содержать сервера со старыми версиями до полного отказа мобильных клиентов от старых версий, тогда и утилизировать старые сервера.
Отличный подход. У нас есть тоже своя система документирования и в какой-то момент, хотелось бы чтобы на каждую версию формировался отдельный документ и была хорошо отлеживаемая история версия) Пока это описываем ручками(декларативно в коде) и держим старые версии эндпоинтов/дто, чтобы можно было отслеживать изменения
Это элементарно, Ватсон, он уже не молод)
А если ваш клиент - мобильные устройства? Могу лишь вам пожелать удачи и набраться терпения, пока весь трафик не переедет на новую версию приложения.
P.S. Абсолютно весь трафик никогда не переедет на новую версию, всегда будут пользователи которые не обновляются, но хотят пользоваться продуктом
А если это минорная версия конкретного эндпоинта, а не мажорная всего API? Я придерживаюсь подхода установки версии после
/apiв случаях с мажорными апдейтами всего сервиса. В Вашем случае при мажорном переезде всего API версия/api/v1может быть занята у эндпоинта в котором Вы делали минорный фикс. И что, в этом случае у Вас будет/api/v2для одного эндпоинта вместо/api/v1для всех?Не согласен с частотой изменения этих версий. В мобильном деве приходилось иметь вплоть до 2-3 версий (из-за необходимости поддерживать эндпоинты для старых версий приложения) и это было далеко не крупное приложение.
При любом подходе придется чем-то жертвовать, и причем всегда финансово) Либо тратить деньги на разработку и поддержку кода, либо тратить деньги на поддержку серверов со старыми версиями)
Почему сломалась? Сейчас проверил - все окей. Ну а чтобы совладать с миграционным адом - поддерживать сервера с разными версиями, как было написано в начале статьи:
В этом случае не нужно поддерживать большинство старого кода. Нужно просто содержать сервера со старыми версиями до полного отказа мобильных клиентов от старых версий, тогда и утилизировать старые сервера.
Отличный подход. У нас есть тоже своя система документирования и в какой-то момент, хотелось бы чтобы на каждую версию формировался отдельный документ и была хорошо отлеживаемая история версия) Пока это описываем ручками(декларативно в коде) и держим старые версии эндпоинтов/дто, чтобы можно было отслеживать изменения