Версионирование API и организация кода

Всё что касается построения API
Ответить
zmt
Сообщения: 4
Зарегистрирован: 2017.04.19, 20:10

Версионирование API и организация кода

Сообщение zmt » 2017.04.19, 20:37

Здравствуйте. Подскажите, пожалуйста, возможные подходы организации кода для версионности REST API.

Ситуация примерно следующая. Есть достаточно большой проект с legacy кодом. 60-70% логики находится в контроллерах. Все контроллеры были организованы в один модуль - v1.
Сейчас пришла необходимость сделать вторую версию API.

Пока вижу два варианта:
1) Перенести существующие контроллеры в common, в модулях v1 и v2 унаследоваться от них. Из минусов - нужно быть очень внимательным, чтобы поддерживать обратную совместимость в v1
2) Унаследовать контроллеры v2 от контроллеров v1. Из минусов - зависимость v2 от v1 (и в будущем v3 -> v2 -> v1) и практически отсутствие возможности отказаться от старых версий API в будущем. Из плюсов - реализовать достаточно быстро

Что можете порекоммендовать? Может можете предложить ещё варианты?

Аватара пользователя
samdark
Администратор
Сообщения: 9251
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Версионирование API и организация кода

Сообщение samdark » 2017.04.19, 22:52

Скопировать контроллеры из v1 в v2.

zmt
Сообщения: 4
Зарегистрирован: 2017.04.19, 20:10

Re: Версионирование API и организация кода

Сообщение zmt » 2017.04.19, 23:52

samdark писал(а):
2017.04.19, 22:52
Скопировать контроллеры из v1 в v2.
Просто скопировать? А в чем заключаются преимущества?
Просто же, например, если нужно будет фиксить баг, то нужно будет не забыть изменить его в нескольких местах (v1, v2, v3)

Аватара пользователя
samdark
Администратор
Сообщения: 9251
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Версионирование API и организация кода

Сообщение samdark » 2017.04.20, 00:02

В том, что стабильность v1 будет стопроцентная и исправляя v2 не будет шансов поломать v1.

Баги обычно не в самом API, а в сервисном слое, который этот API дёргает.

zmt
Сообщения: 4
Зарегистрирован: 2017.04.19, 20:10

Re: Версионирование API и организация кода

Сообщение zmt » 2017.04.20, 00:27

samdark писал(а):
2017.04.20, 00:02
Баги обычно не в самом API, а в сервисном слое, который этот API дёргает.
Это да, но код legacy и 60-70% логики прям в контроллерах. Сервисного слоя почти нет.

С ресурсами, получается, так же нужно будет поступить и скопировать?

Аватара пользователя
samdark
Администратор
Сообщения: 9251
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Версионирование API и организация кода

Сообщение samdark » 2017.04.20, 01:19

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

Ну да. Если v1 API остаётся только для совместимости, то копировать — нормальное решение.

zmt
Сообщения: 4
Зарегистрирован: 2017.04.19, 20:10

Re: Версионирование API и организация кода

Сообщение zmt » 2017.04.20, 10:28

Спасибо. Примерно так и поступлю. Но
samdark писал(а):
2017.04.20, 01:19
По времени что наследоваться что потихоньку вытаскивать сервисный слой будет примерно одно и то же...
С этим не могу согласиться. Например, унаследоваться от 20 контроллеров и 40 ресурсов это примерно 30-40 мин. А вот вытаскивать всю логику в сервисный слой и оттестировать не сломалось ли чего (да, тестов тоже нет) это займет гораздо большей времени. Хотя понимаю, что так дальше продолжаться не может и вытаскивать всеравно надо будет...

Аватара пользователя
samdark
Администратор
Сообщения: 9251
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Версионирование API и организация кода

Сообщение samdark » 2017.04.20, 11:53

А, ну если тестов нет, тогда да...

Ответить