Jakie macie sposoby na utrzymanie kilku wersji API

Cześć,
Jak sobie radzicie z utrzymywaniem kilku wersji rozwijanego przez was API kiedy rozwijając nową wersję musicie utrzymywać również poprzednie?

To znaczy mamy jakieś metody wystawione jako API. W nowej wersji część zmienia swoje działanie, dochodzą nowe, zmieniają się jakieś stałe ... jednocześnie musimy utrzymywać wersję poprzednią i dokonywać w niej niezbędnych poprawek. Najprostsze rozwiązanie: skopiować całość nazwać API2 i poprawiać obie wersje... Ale wtedy duplikacja kodu jest taka że aż zęby bolą. Jakieś bardziej "smart " rozwiązanie ? W tej chwili dziedziczę API2 po API1 i nadpisuję zmienione działanie ale jest to czasem ciężkie do czytania.

Troche nie za bardzo rozumiem co znaczy dziedziczenie API2 po API1. Ja to rozumiem tak, i wydaje mi się że to spoko sposób wersjonowania:

1. Mamy warstwę kontrolerów i warstwę serwisów
2. Jesli chcemy API2 to robimy nowy kontroler, z urlem takim samym jak poprzednio, tylko zamiast /api/v1/ jest api/v2/
3. No i teraz kwestia logiki w API2:
   3a) Część logiki która jest taka sama, to nic nie kopiujemy, po prostu dalej korzystamy z istniejących serwisów
   3b) Część nowej logiki to albo nowe serwisy, albo inne implementacje interfejsów, albo nower serwisy co dziedziczą ze starych i zmieniają kilka rzeczy
4. Profit

Jeśli nie mamy warstwy kontrolerów i wystawiamy tylko API interfejsów, no to tak, dziedziczymy bądź tworzymy nowe.

Jedyne pytanie jakie się może pojawić to Czy w takim razie zmieniając coś w istniejących serwisach, muszę uważać czy by nie zepsuć czegoś w nowym API2??? Odpowiedź brzmi - testy

najnowsza wersja w masterze, stare wersje utrzymywane jako branche (z datą ważności), nowe Api to nowa instancja (wersjonowane przez url),
some-service.com/v2/... -> (branch) master
some-service.com/v1/... -> (branch) v1

żadnej duplikacji kodu.

Jeśli nie mamy warstwy kontrolerów i wystawiamy tylko API interfejsów, no to tak, dziedziczymy bądź tworzymy nowe.

Mętnie pisałem, ale chodziło mi własnie raczej o wersjonowanie samego API bez warstwy kontrolerów. Np.

class MojeApiV1 {
	public int metoda1 {...}
}

class MojeApiV2 extends MojeApiV1 {

	@Override
	public int metoda1{ coś zmieniłem}
}

Problemy się pojawiają w przypadku metod statycznych - ich nie przeciążę nowymi wersjami. W przypadku takich klas narzędziowych używam niestety wersjonowania samych metod czyli:

class MojeToolsy {

 public static int metoda1 {}	
 public static int metoda1_V2 {}
}

ale mi się to cholernie nie podoba ;)

Jedyne pytanie jakie się może pojawić to Czy w takim razie zmieniając coś w istniejących serwisach, muszę uważać czy by nie zepsuć czegoś w nowym API2??? Odpowiedź brzmi - testy

To jest oczywiste :D

Generalnie chodziło mi o potwierdzenie czy dziedziczenie na w tym przypadku sens czy szukać jakiegoś innego rozwiązania. Na pewno utrudnia ono czytanie i debugowanie takiego serwisu przy powiedzmy 5 wersji ;)

rubaszny_karp napisał(a):

najnowsza wersja w masterze, stare wersje utrzymywane jako branche (z datą ważności), nowe Api to nowa instancja (wersjonowane przez url),
some-service.com/v2/... -> (branch) master
some-service.com/v1/... -> (branch) v1

żadnej duplikacji kodu.

Nie mogę tak. Wersje api funkcjonują w ramach jednego wspólnego serwisu - nie mój pomysł ;) Zawsze w ten sposób zresztą działałem, a tym razem trafił się przypadek szczególny :). Jedyną wadą tego rozwiązania była z kolei konieczność nanoszenia fixów na starsze wersje osobno.