@ SamaraSoucy-MSFT верна - все опции действительны. Способ best очень субъективен, но я более подробно остановлюсь на определенных c опциях для управления версиями API.
Управление версиями API ортогонально вашей инфраструктуре. Если вы хотите разделить вещи на отдельные приложения или добавить другие уровни изоляции, это поддерживаемый сценарий. Понятие Версия объявления описывает это в некоторых деталях. Вкратце, ваше приложение может рекламировать версий API, которые не размещены в этой конкретной реализации. Существует много способов добиться рекламы версии, поэтому нет конкретных указаний c о том, как это сделать. В самой простой модели вы просто обновите свое приложение новыми соглашениями, атрибутами и т. Д. c. Тем не менее, очень вероятно, что желание не вносить никаких изменений в существующие развертывания. Это означает, что вам нужно найти способ обновить эту информацию вне приложения (например: config, db, et c) или до go объявления о версии. Это частично зависит от того, насколько изолирована каждая реализация. Если вас не интересует реклама доступных или устаревших версий API, то это не проблема.
Существует как минимум 4 способа достижения ваших целей с помощью управления версиями API.
Опция 1 - Копировать, Вставить, Заменить
Метод Копировать, Вставить, Заменить (CPR) включает буквальное копирование и вставку предыдущей версии службы в новую папку и новое пространство имен кода. Это формирует базовую линию новой версии из предыдущей версии без изменения оригинала. Различия в новой версии затем заменяются при необходимости. Этот процесс может повторяться столько, сколько вы захотите.
Если ваши изменения довольно минимальны между версиями, это может быть очень простой и эффективной стратегией. Ключевым недостатком является раздувание и связь реализации с течением времени. Если у вас есть solid политика управления версиями (например, N-2 ), то это может минимизировать влияние. Самой большой проблемой было бы внесение значительных изменений в реализацию, которые не имеют смысла совмещать или могут привести к изменению предыдущих версий. Такой пример будет пытаться разместить 1.0 с ASP. NET Web API и 2.0 в ASP. NET Core в той же реализации.
Я видел этот подход используется несколько раз, и это может быть эффективным.
Вариант 2. Внедрение и составление
В этом варианте каждая версия будет реализована в отдельной сборке API. У вас будет хост-приложение API, которое внедряет и составляет всех API из каждой версионной сборки. Это обеспечивает полную изоляцию между реализациями, которые по-прежнему обладают всеми преимуществами управления версиями API.
Как и Опция 1 , вы все равно должны рассмотреть возможность раздувания; тем более что каждая сборка, вероятно, имеет разные зависимости. Также было бы довольно сложно разместить API, созданные для разных платформ, но это должно быть технически осуществимо.
Вариант 3 - Отображение заголовка хоста
Большинство веб-серверов имеют какой-то способ отображения Host заголовок для разных приложений. Вы можете использовать эту технику для размещения каждой версии приложения в качестве независимого приложения.
Вариант 4 - Шлюз
Использование шлюза обеспечивает наибольшую гибкость, но может быть самым сложным в настройке. Этот метод может использовать любое количество методов маршрутизации, таких как DNS, перезапись URL-адреса или перенаправление URL-адреса на основе доступной информации о версии в запросе. Конечная точка, скорее всего, является изолированным приложением, таким как Option 3 . Шлюз отвечает за пересылку или перенаправление запроса к правильной конечной точке версии.
Я свободно использую термин gateway . Это может существующий сервис или платформа, аппаратная или по вашему собственному дизайну. Это будет зависеть от ваших потребностей и от того, сможет ли их удовлетворить готовое решение.
Дополнительные соображения
Это, конечно, не единственные варианты и они не являются взаимоисключающими. Вы можете комбинировать любые их варианты в соответствии с вашими потребностями.
Выбор Опция 3 или Опция 4 будет сопряжена с некоторыми трудностями для управления версиями API, поскольку барьеры физической изоляции выходят за пределы каждое развернутое приложение. Вам нужно будет либо придумать способ обновить рекламируемые версии, либо полностью отказаться от этого понятия, как указано выше. Если в конечном итоге вы вообще не рекламируете версии, то каждая развернутая реализация должна быть единой, независимой базой кода, которая, скорее всего, сводит на нет необходимость API-версий, поскольку она обрабатывается на уровне абстракции.
Ваша общая стратегия и политика управления версиями также будут играть роль. Если вы используете симметричную проверку в своих сервисах, дизайн URL и версии API будут одинаковыми для всех, но поставляются с дополнительными развертываниями для удовлетворения этого требования. Если вы решите иметь независимые, развивающиеся сервисы, то обнаружение версии и реклама станут более интересными. Например, ваша политика может указывать, что устаревшая версия выйдет на закате через 6 месяцев. Клиенты должны затем обнаружить эту рекламу , не используя контрольный заголовок api-deprecated-versions. Обнаружение версии может поддерживаться с помощью метода HEAD и / или OPTIONS.