Подход к управлению версиями и устареванием для API REST в микросервисах

Question

Вот мое требование: 1. Версия конечных точек REST 2. Избегать дублирования кода 3. Устаревший APIS

Вот пример конечной точки REST: GET: https: /// www.thisatests.com/v1/users

GET: https: /// www.thisatests.com/v2/users

Здесь структуры ответов v1 и v2 совершенно разные. Номер версии является переменной пути.

Вопрос о подходе к реализации:

1. Должны ли мы иметь 2 разных кодовых базы, чтобы избежать дублирования кода?
2. Должны ли мы иметь 2 разных Микро-сервисы, работающие на v1 и v2?
3. Должны ли мы иметь один микро-сервис, обслуживающий как v1, так и v2?

В идеале мы не хотим раскручивать 2 разных микро-сервиса. сервисы для выполнения этой задачи и не хотят иметь разные базы кода для этого.

Мы используем SpringBoot для разработки REST API. Я знаю, что мы можем добавить аннотации на уровне класса или функции в контроллерах.

Я хочу знать, каков наилучший подход для реализации управления версиями, чтобы «с одинаковой кодовой базой (без дублирующегося кода) и одним микро-сервисом» как это можно сделать?

Примечание. Когда я скажем, та же самая кодовая база и дубликаты означают: например. Если я использую тот же метод контроллера для получения сведений о пользователях, основанных на изменениях формата ответов v1 и v2. Так что мне придется помещать такие вещи, как «если v1 или if v2», которых я хочу избежать.

Если я напишу в контроллере 2 разных функциональных контроллера, как обработать устаревший apis? Как почистить код? В любой момент времени мы хотим поддерживать только 2 версии apis. С учетом вышеуказанных ограничений, что будет лучшим подходом?

Спасибо.

Answer 1

Из моего опыта я бы сказал, что эти две конечные точки можно рассматривать как отдельные сервисы (функциональные возможности), предоставляемые одним и тем же микросервисом. Это означает, что у вас должна быть одна кодовая база для поддержки обеих функций. Вы можете повторно использовать свои коды в возможных частях, но это не всегда возможно или осуществимо.

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

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