Есть некое клиент-серверное приложение (оригинально, да). Предполагается раз в 2 недели выпускать новую версию. Если серверную часть технически обновить вполне легко, клиентская часть обновляется по желанию пользователей — могут и вообще не обновлять 2 месяца. После удара головой об стену возникла нездоровая мысль — с выпуском каждой новой версии тупо делать полную копию API — интерфейсы и DTO:

Версия 1:

public interface IApiV1
{
  ThingDTOV1 GetThing(int thingId)
}

public class ThingDTOV1
{
  public int ThingId { get; set; }
  public string ThingDescription { get; set; }
}

Версия 2 начинается с полной копии V1:

public interface IApiV2
{
  ThingDTOV2 GetThing(int thingId)
}

public class ThingDTOV2
{
  public int ThingId { get; set; }
  public string ThingDescription { get; set; }
}

А продолжается деланьем абсолютно любых правок:

public interface IApiV2
{
  ThingDTOV1 GetThing(string token, int thingId) // API поменялся
}

public class ThingDTOV2
{
  public int ThingId { get; set; } // это так и было
  public string Description { get; set; } // отрефакторили
  public string ExtendedDescription { get; set; } // добавили новое
}

При релизе старый API делается доступным по адресу /v1, новый — по адресу /v2. Старые клиенты работают только со старым, новые — только с новым. Детали реализации (по возможности) изолированы и используются (по возможности) всеми версиями. С выходом каждой новой версии убивать одну самую старую — например гарантировать доступность 10 последних версий. В результате копипаст не разрастается, а ограничен "размером" обратной совместимости.

Подскажите пожалуйста какие могут быть подводные камни.

Здравствуйте, andyag, Вы писали:

A>Подскажите пожалуйста какие могут быть подводные камни.

Я бы сделал механизм обновления клиентов и не держал бы более 2-3 версий API. Все же поддерживать 10 API это как-то путано.

Бонус: не на все 100% по теме, но может натолкнуть на мысли:
Внутренний опыт компании Microsoft по автоматической сборке и непрерывной интеграции веб сервисов и приложений с помощью TFS 2012

Здравствуйте, Doc, Вы писали:

Doc>Здравствуйте, andyag, Вы писали:

A>>Подскажите пожалуйста какие могут быть подводные камни.

Doc>Я бы сделал механизм обновления клиентов и не держал бы более 2-3 версий API. Все же поддерживать 10 API это как-то путано.

Клиент — нативное iPhone-приложение. Там, насколько мне известно, невозможно заставить — можно только предложить. Поэтому "ну и фиг с вами" возможен только в самом крайнем случае — например для версий 3-месячной давности. По релизу раз в 2 недели, 3 месяца — это что-то типа 6-7 одновременных версий.

Doc>Бонус: не на все 100% по теме, но может натолкнуть на мысли:
Doc>Внутренний опыт компании Microsoft по автоматической сборке и непрерывной интеграции веб сервисов и приложений с помощью TFS 2012
Дядька там неприятный какой-то

Официально рекламируемый подход Microsoft для WCF — это такой не очень тривиальный набор правил, предполагающий разделение на ломающие и неломающие правки, с последующим уточнением и принятием решения — то ли делать что-то новое, то ли изменять существующее. Подход понятен, подход имеет смысл, но я слабо себе представляю такое на практике. Более того, этот подход предполагает заинтересованность в обратной совместимости ("расширения" ничего не ломают), требуя некоторого дополнительного мыслительного оверхеда от разработчика, а у меня такой заинтересованности нет. Более того, возникают вопросы вроде "а как бы мне так писать функциональные/интеграционные тесты, чтобы требования для всех актуальных версий сохранять". Мой подход "головой об стену" вполне тривиален и однозначен: есть возможность почти независимо чинить, тестировать и разворачивать любую из актуальных версий, т.к. это фактически десяток "никак не связанных" сервисов, опционально использующих одну общую библиотеку с бизнес-логикой. При этом у каждого из сервиса свой интерфейс, по необходимости — своя частичная реализация и свой набор функциональных тестов.

Здравствуйте, andyag, Вы писали:

A>Клиент — нативное iPhone-приложение. Там, насколько мне известно, невозможно заставить — можно только предложить. Поэтому "ну и фиг с вами" возможен только в самом крайнем случае — например для версий 3-месячной давности. По релизу раз в 2 недели, 3 месяца — это что-то типа 6-7 одновременных версий.

10 версий API за 3 месяца? Вы их как пирожки печете? Может ответственнее подходить к их проектированию.

A>Дядька там неприятный какой-то

Главное интересно рассказывает.

Здравствуйте, Doc, Вы писали:

Doc>Здравствуйте, andyag, Вы писали:

A>>Клиент — нативное iPhone-приложение. Там, насколько мне известно, невозможно заставить — можно только предложить. Поэтому "ну и фиг с вами" возможен только в самом крайнем случае — например для версий 3-месячной давности. По релизу раз в 2 недели, 3 месяца — это что-то типа 6-7 одновременных версий.

Doc>10 версий API за 3 месяца? Вы их как пирожки печете? Может ответственнее подходить к их проектированию.

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

Здравствуйте, andyag, Вы писали:

A>Подскажите пожалуйста какие могут быть подводные камни.
Подводный камень, по большому счёту, один: объём регрессионного тестирования.
В каждой версии вы чуть-чуть добавляете функциональности: или усложняете методы, или добавляете новые. В общем, площадь поверхности у вас увеличивается в K раз.
Поддерживать одновременно N версий эквивалентно одному API площадью в сумму площадей всех версий. Т.е. общая сложность получается sum(1..N, С0*K^N) = С0*(K^N-1)/(K-1).
То есть коэффициент увеличения объема тестов по сравнению с поддержкой одной версии равен (K^N-1)/(K-1). Много это или мало?
Вот несложная табличка со значениями этого коэффициента для N=10:

 1%    10.46221254
 5%    12.57789254
10%    15.9374246
15%    20.30371824

То есть если вы дописываете 1%, то рост — всего лишь в 10 раз. Если 15 процентов, то рост объёма тестирования будет уже в 20 раз.

Без регрессионных тестов вы быстро сломаете старые версии API — ведь они работают с единым ядром сервиса, которое вы непрерывно изменяете.

может иметь одну серверную часть на каждую версию? если баг нужно пофиксить — фиксить на бранче, либо оставлять как есть чтобы подтолкнуть юзеров к апдейту,
если нужны данные со старых версий — делать интеграцию с каждой версии на последнюю (тоже сервер сайд, не должно быть особых проблем)

соответственно енд поинт для всех версий один и форвардит реквесты на нужный сервер в зависимости от версии

A>Подскажите пожалуйста какие могут быть подводные камни.

Про регрессионное тестирование рядом хорошо написано.

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

Нормальная тема — отобрать у клиентов свободу обновления. Например, научиться давать ему сообщение, что "Доступно обновление. Установить?". А со временем — "Ваша версия устарела и не поддерживается. [Установить новую]/[Выход]"

А на серверной стороне, как ни крути, контракт/интерфейс сервиса, и его обратная совместимость — это святая корова. Если вы не контролируете клиентов — изменения внедрять придётся медленно и по плану.