Использование отдельного каталога для каждой версии API

Я планирую создать API с базой Laravel. И может быть несколько версий API, если я продолжу его разработку, например: v1, v2, v3 и т.д.

И вместо того, чтобы иметь только одну копию структуры Laravel и версию API внутри нее, создавая разные каталоги для каждой версии, я собираюсь создать полностью отдельную копию структуры Laravel для каждой версии API.

Например, предположим, что это URL-адрес API: website.com/api, я собираюсь создать каталог под v1 внутри каталога api и поместить в него полную копию Laravel. И позже, когда мне нужно создать новую версию API, я создам еще один новый каталог под названием v2 рядом с v1 и поставлю в него новую полную и отдельную копию Laravel и т.д.

Таким образом, когда я хочу получить доступ к версии 1 API, я получаю доступ к этому URL-адресу: website.com/api/v1, и когда я хочу получить доступ к версии 2, я получаю доступ к website.com/api/v2.

Мой вопрос: Это плохая идея? И каков недостаток этого подхода?

Edit:

Почему я подумал об этом?

Потому что я думал о следующих моментах:

Что, если я когда-нибудь захочу создать новую версию API с фреймворком PHP, отличным от Laravel.
Что, если я захочу, когда-нибудь создать новую версию API с языком программирования, отличным от PHP.
Что делать, если я когда-нибудь захочу перейти на более новую версию Laravel, и эта версия имеет значительные изменения в версии, изначально созданной API.

Ответ 1

Я считаю, что это плохая идея - кучи дублированного кода, дублирование обслуживания и абсолютно никаких преимуществ.

Создать для текущего случая использования

Прежде всего:

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

Поэтому многие архитекторы CTO/технологии ошибаются, иногда думая слишком много о будущем. Что делать, если мой объем увеличивается на 1000x? Должен ли я использовать большой стек данных? Нет, конечно, если вы не ожидаете, что это произойдет в ближайшие 3 месяца!

Недостатки вашего подхода

Двусторонность кода:. Вы в конечном итоге дублируете так много кода - ваши модели Eloquent, бизнес-логику, аутентификацию, промежуточное ПО и т.д.
Обслуживание и другие накладные расходы: В зависимости от вашего технического стека обслуживание также будет дублироваться. Напр. Представьте, что вы запускаете команды Artisan для нескольких приложений для простого обновления кеша конфигурации. Не говоря уже о отдельных обновлениях зависимостей, аппаратных ресурсов и т.д.

<сильные > Преимущества

Нет очевидных преимуществ вашего подхода. Давайте рассмотрим конкретные вопросы, которые привели вас к этой архитектуре:

Что, если я захочу, когда-нибудь создать новую версию API с фреймворком PHP, отличным от Laravel?

Скажем, у вас в настоящее время есть 3 версии, и вы хотите создать версию №4 в другой структуре. Ну, у вас все еще могут быть первые 3 версии в одном приложении Laravel и 4-й версии на другом приложении/кодовой базе. Если у вас уже есть 3 существующие версии, нет никаких причин, чтобы использовать их в качестве отдельных приложений Laravel.

Что, если я захочу, когда-нибудь создать новую версию API с языком программирования, отличным от PHP.

Хорошо, то же самое относится и к нам. У вас всегда могут быть разные приложения для будущих версий на разных языках, если возникают такие ситуации.

Что делать, если я когда-нибудь захочу перейти на более новую версию Laravel, и эта версия имеет значительные изменения в версии, изначально созданной API.

Малые версии обратно совместимы в Laravel. Итак, если вы обновляетесь с Laravel 5.1 до 5.5, изменений не должно быть. Для основных из них вы можете выбрать различные приложения (если требуется), но на самом деле даже основные обновления могут не быть проблемой. Конечно, вы можете использовать такие инструменты, как Laravel Shift, чтобы упростить вам обновление

Ответ 2

Мои рекомендации:

Использовать субдомены

Пусть ваш API будет доступен по таким URL- mobile.laravel.app как: mobile.laravel.app или api.laravel.app.

Это дает вам гибкость в использовании другого сервера (и, следовательно, другой платформы) для вашего API или продолжения использования того же приложения Laravel для вашего приложения. Вы можете использовать субдоменную маршрутизацию в laravel для обработки нескольких доменов с использованием одного и того же приложения.

Ваша стратегия управления версиями

Как правило, номер версии api сохраняется как {major}. {Minor} (встроенный в семантическое управление версиями). Несовершеннолетние обратно совместимы.

например

api.laravel.com/v1.2/...

или же

v1.api.laravel.com/...

(особенно, если он указывает на другой IP-адрес).

Опять же, вы можете указать другой сервер или папку, или другой контроллер, в зависимости от того, какие изменения вы делаете.

Использование Laravel для версионного API

Большинство проектов, над которыми я работаю, относятся к Laravel, и именно так мы работаем с версионированием в Laravel.

Апис получен на поддомене как: api.laravel.app

API являются версионными и доступны по адресу api.laravel.app/v1/... или api.laravel.app/v2/...

Контроллеры, обрабатывающие эти API, сгруппированы в папки

App
|-Http
  |-Controllers
     |-API
        |-v1
           - controllers for v1
        |-v2
           - controllers for v2

Если в будущем вы захотите сменить серверы, платформу или использовать другую версию laravel и т.д. - вы можете работать через другой поддомен.

Я бы по-прежнему рекомендовал работать над "дорожной картой", функциями и версиями ком-шаблонов в течение следующих 3–6 месяцев.

Ответ 3

Я думаю о создании полностью отдельной копии Laravel рамки для каждой версии API.

Почему вы хотите дублировать всю структуру, нет смысла делать это. В этом случае у вас будет много версий одного и того же файла, и это приведет к дублированию кода. Что, если вы обнаружите ошибку в общем методе среди всех версии, вы должны изменить его во всех версиях.

Что, если я когда-нибудь захочу создать новую версию API с фреймворком PHP, отличным от Laravel.

Что, если я захочу, когда-нибудь создать новую версию API с языком программирования, отличным от PHP.

Что, если я когда-нибудь захочу перейти на новую версию Laravel, и эта версия имеет значительные изменения в версии, которую API был создан с помощью.

Все ваши 3 пункта не связаны с тем, как вы организуете свой API, как только вы меняете язык или фреймворк, вам придется переписать его, за исключением изменения только версии.

И создание структуры API, основанной на предвидении изменения языка или структуры, не имеет смысла. Ebay, Paypal, Facebook, Google и т.д., все изменили свой язык выбора и переписали свою базу кода в определенный момент времени. Они не предвидели этого изменения и сделали свою систему в соответствии с этим.

Таким образом, я вижу много недостатков.

Подход 1:

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

Преимущества:

Легко переключаться между
Удобно с IDE, так как не будет одинаковых файлов имен для поиска и редактирования, поэтому вы не будете редактировать другую версию по ошибке.
Каждый раз, когда вы можете обновлять любую версию.
См. историю изменений
многое другое, которое вы испытаете при разработке с этим подходом к копиям разных папок.

Подход 2:

Еще один вариант, который я могу видеть, и я сделал это, группируя ваш API с префиксом конкретной версии. Если вы хотите, чтобы все версии работали одновременно с одной копией. Но это менее рекомендуется.

Измените имя метода или имя контроллера в соответствии с версией или поместите их в пространство имен, зависящее от версии

Смотрите фрагмент ниже:

/* Version v1  */
Route::prefix('v1')->group(function () {
    Route::get('users','[email protected]');
    Route::get('foobars','[email protected]');
});

/* Version v2  */
Route::prefix('v2')->group(function () {
    Route::get('users','[email protected]'); 
    Route::get('foobars','[email protected]');
});

Преимущества:

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

Примечание. Оба являются ситуационными подходами, если в новой версии меньше 5 или 10 изменений, я бы пошел на подход 2. Однако это индивидуальный конкретный выбор.

Ответ 4

Да, вы правы. Это очень плохая идея. И задача состоит в том, чтобы даже думать о единственном преимуществе, но его нет.

Я рекомендую вам установить одну установку, и вы можете использовать Dingo API. Пакет, который предоставит вам набор инструментов и стандартных API-интерфейсов прямо из коробки. Включая версии, такие как v1, v2, как вы хотите.

Это улучшит повторное использование кода наряду со многими другими вещами, которые помогут вам создать стандартный API.

Удачи.

Ответ 5

Это не совсем ответ на этот вопрос, и, поскольку вы сказали, что "планируете" использовать laravel, я хочу рекомендовать другую платформу, поддерживающую версии REST API.

https://apigility.org/

Apigility, используйте zendframework в качестве базы, если вы заинтересованы в использовании другой структуры, я рекомендую ее.

Ответ 6

Если я правильно понял, вы "смешиваете" свою архитектуру разработки и развертывания.

Я не вижу в вашей производственной среде каких-либо проблем с множественными версиями вашего API на основе URL-адреса (как вы сказали) или даже поддоменов.

Ваша версия управления (git, svn и т.д.) должна заботиться о каждой версии API, которую вы можете иметь. Если вы хотите разработать новую версию: создайте новую ветвь, разверните и протестируйте ее, затем создайте тег.

Затем, при развертывании самого приложения, вы должны заботиться о том, как сделать его доступным через определенный путь или домен.