Utrzymywanie kilku wersji WebAPI

Myślę, że to zbytni komplikacja, lepiej dawać dłuższy okres na przygotowanie aplikacji do zmian i wprowadzać zmiany możliwie nieinwazyjnie (czyli jeśli jakaś zmiana nie jest niezbędna to wprowadzać ją tak, by aplikacje bez wprowadzenia zmiany też działały).

Moim zdaniem złe rozwiązanie.
Popieram przedmówcę.

No to bardzo mnie ciekawi, co rozumiecie Panowie przez wprowadzenie zmian "możliwie nieinwazyjnie"? I co w tym momencie da "dłuższy okres na przygotowanie aplikacji do zmian", skoro ostateczne wprowadzenie zmiany i tak doprowadzi do paraliżu aplikacji, jeśli zmiany nie będą wstecznie kompatybilne? Czy Waszym rozwiązaniem jest wtedy siedzenie cały dzień, na kiedy zaplanowane jest wdrożenie i sprawdzanie czy stara wersja aplikacji jeszcze działa czy już może trzeba uruchomić tą nową (oczywiście nieprzetestowaną, bo na TestWebAPI zmiany zostaną wprowadzone w tym samym momencie co na produkcyjnym Allegro)? 

Dlatego ja postulowałem żeby ten pomysł był niżej ponieważ powinno być tak że środowisko testowe wdraża zmiany pierwsze. Wtedy można przetestować naszą integrację z nową wersją, później zmiana produkcyjna.

Jaka to różnica czy mamy 3 wersję czy 1 produkcyjna skoro na żadnej nie możesz nic przetestować tak naprawdę ?

Taka, że jeśli prowadzisz naprawdę dużą aplikację, to nie musisz na hurra w przeciągu tygodnia (niech będzie nawet dwóch) na wariata i bez dokładnych testów wprowadzać zmian, bo "zaraz Allegro zepsuje mi program". Na spokojnie używasz starszej wersji API oznaczonej jako "deprecated", która w naturalnym trybie najpierw otrzyma to oznaczenie, a dopiero potem zostanie wycofana. Chcesz dobry tego przykład? Zapraszam do lektury API eBay http://developer.ebay.com/DevZone/xml/docs/WebHelp/ReleaseNotes.html . Tam utrzymywanych jest około 20 ostatnich wersji i jest zaplanowany _dokładny_ cykl ich zarzucania (ogłoszony dużo wcześniej).

Pan Michał ma jednak rację, pisałem program pod ebay API i rzeczywiście rzuciło mi się w oczy, że są metody przestarzałe i są różne wersje API.

Więc wydaje się to dobre rozwiązanie, bo chyba bez sensu by go nie stosował tak duży serwis.

Czyli jest to rzecz ważna do zrobienia po naprawieniu środowiska testowego

Zespół nie panuje nad jednym serwisem, a co dopiero nad kilkoma :)

Ale coś w tym jest. Upgrady powinny być bardziej płynne, a nie "wdrożyliśmy nowe zmiany" i programiści nie śpią po nocach bo ich programy przestały działać.

Uważam to za doskonały pomysł, w końcu skończyłyby się problemy po zmianach w API.