Рекомендации по обратной совместимости API

Ответ 1

Выпуск новой версии API - это очень редкая вещь. Обычно вы можете добиться обратной совместимости, просто добавив новые необязательные параметры или новые методы. Например, если у вас есть метод с именем search, но теперь вы недовольны тем, как он работает, вы можете иметь дело с ним различными способами:

• Если это простое изменение, вы можете добавить новый параметр mode, который по умолчанию равен mode1 (поэтому он совместим с обратной связью). Если пользователь поставляет mode2, вы обнаруживаете его с надлежащим условием if, как вы сами предложили. (Кроме того, обычно вы можете думать о лучшем имени, чем "режим".)

• Если изменение является большим, вы можете добавить новую службу search2, которая использует новый интерфейс. Затем вы отмечаете метод search как устаревший (но все же рабочий и обратно совместимый). Обычно, когда вы это делаете, вы можете реорганизовать свой код таким образом, что почти вся логика находится внутри метода search2, а ваш старый метод search вызывает search2 внутренне с измененных параметров (и соответствующим образом переформатирует результаты). Если вы сделаете это правильно, вам больше не понадобится изменять метод search. Когда вы изменяете свои таблицы и т.д., Вам нужно будет только изменить search2.

Моя точка зрения заключается в том, чтобы не выпускать N+1 -st версию API. Такой большой выпуск подразумевает значительные изменения в ВСЕ ваших методов, а не только один. Многие крупные API никогда не выпускали версию 2 своего API, они все еще используют версию 1, просто слегка изменяют ее части, как в приведенном выше примере.

Если вы абсолютно уверены о выпуске N+1 -st версии вашего API, создайте новые точки входа для ВСЕ ваших методов. Если у вас есть папка с именем services, создайте новую с именем services-v2. Обновите свой код services так, чтобы он использовал большую часть services-v2. Если вы считаете, что это слишком сложно, я думаю, вам еще не нужна N+1 -st версия вашего API.

Кстати, не путайте централизованные API (например, Карты Google) с распределенными (например, Android). Android выпускает новые версии API все время, потому что есть миллиарды Android-серверов (каждое Android-устройство - одно), и все они не могут быть просто удалены Google удаленно. Следующая версия Android по-прежнему совместима с предыдущей версией, номер увеличивается только для обозначения новых функций.. Вы все еще можете запускать приложения, созданные для Android 3.0 на Android 7.0 (пользователь может получить дополнительные предупреждения, но приложение будет работать). Разработчики Android-приложений используют эти цифры для описания "минимальных требований" к своим приложениям. В то время как централизованные API обычно увеличивают свой номер версии, указывая на значительное отставание от несовместимого изменения.

Ответ 2

Я думаю, у вас уже есть разделение проблем. Я имею в виду, что получение данных для вашего приложения выполняется только с помощью модели (например).

Поэтому вам нужно только изменить модель.

Я предлагаю, что есть только одна точка входа: файл "router" . Этот файл проверяет требуемую версию API и загружает правильный файл. Таким образом, вы получаете разные файлы для каждого API. Файл "router" не будет очень большим, и каждая новая версия API будет иметь свой собственный файл, поэтому вы не будете смешивать все.

Например, в файле "router" :

function dispatch() {
    switch (APIVersion) {
    case 1:
        use('file.1.ext');
        break;
    case 2:
        use('file.2.ext');
        break;
    case 3:
        use('file.3.ext');
        break;
    }
}