Использование отдельного каталога для каждой версии 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,

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


Редактировать:

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

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

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

10

Решение

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

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

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

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

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

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

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

преимущества

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

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

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

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

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

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

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

7

Другие решения

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

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

Пусть ваш API будет доступен по URL, как: 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 и т. Д., Вы можете работать через другой поддомен.

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

6

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

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

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

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

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

Так что я вижу много недостатков.

Подход 1:

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

введите описание изображения здесь

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

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

Подход 2:

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

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

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

/* Version v1  */
Route::prefix('v1')->group(function () {
Route::get('users','UsersController@index');
Route::get('foobars','FooController@bar');
});

/* Version v2  */
Route::prefix('v2')->group(function () {
Route::get('users','UsersController@index');
Route::get('foobars','FooController@bar');
});

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

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

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

5

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

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

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

Удачи.

0

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

https://apigility.org/

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

0

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

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

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

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

0
По вопросам рекламы ammmcru@yandex.ru
Adblock
detector