Поддержка нескольких версия API приводят к костылям?
Всем привет!
Предположим приложение которое работает с первой версией API, умеет определять только BB тег [IMG=image.jpg].
Допустим, во второй версии API добавляется тег [VIDEO=//youtu.be/h3vd3g3]
Т.к. подключение к БД в любом случае общее, скажем class Posts, то классы обеих версий работают именно с этим классом. А он, соответственно, отдает и теги VIDEO, т.к. они же есть в базе.
Я ничего не придумал лучше как в классе /api/v1/getPosts.php создать дополнительный метод, который выполняется после метода Posts->getFromDb(), он будет искать теги VIDEO, удалять сам тег и оставлять только ссылку. И вроде как все нормально НО....
Предположим появляется третья версия приложения, которая работает с третьей версией API, где появился тег [QUOTE].
Получается, что при создании третьей версии API, я должен вернуться к первой версии и добавить в наш костыльный метод еще один тег для удаления, а во второй версии так же создать такой же метод, который будет удалять только QUOTE
Я может не понял, но в вашем примере каждая следующая версия расширяет функционал предыдущей, что позволяет клиенту первой версии спокойно пользоваться третьей.
В этом случае как-то разделять их нет необходимости.
Вот когда очередная версия ломает обратную совместимость (путем изменения/удаления полей, entrypoints, более строгой валидации), то в этом случае вам необходимо иметь две разных версии API.
Да, возможно я не самый лучший пример привел... Точнее правильный, но не полный...
Не берите в учет то, что добавляется только BB тег. Представьте, что добавляется функционал ломающий совместимость, а вместе с ним параллельно еще и BB тег.
Хотя в приведенном Вами примере, так же не понятно как контролировать. Ведь пользователи первой версии приложения также будут видеть вместо форматированного текста, обычный BB код. т.к.Приложение его не понимает
Зависит от выбранной вами политики по-умолчанию по отношению к необработанным BB-кодам. Вы можете оставлять их текстом, либо вырезать. И в том и другом случае при добавлении новых BB-кодов в новые версии API вам не придется трогать старые версии.
Так же есть вариант не отдавать контент с новыми кодами в старую версию API, которая не умеет корректно его обрабатывать.
В зависимости от проекта и потребностей можно сделать по разному, но в любом случае не особо приветствуется внесение изменений в архивные версии, есть на это нет острой необходимости (например в плане безопасности).
Но и это определяется политикой по отношению к времени поддержки старых версий API.
Сложный
Простой
