Вопрос скорее академический чем практический (т.е. готовые фреймворки/решения для rest api не особо интересны) интереснее обсудить. Как организовать учет версий АПИ? Преамбула В свое время разрабатывал ресурс, оказавшийся первым и очень полезным в определенной нише. Для своих технических целей сделал RESTApi. Поскольку клиента тоже делал я, и изменения вносились одновременно проблема с версиями не возникала. Потом "случайно" выяснилось, что это очень нужно одному клиенту, потом другом..... и понеслась... Пользоваться стали многие, но т.к. это была не официально обещанная фича - проблемы с версиями вообще не волновали, даже потенциально. Увы проект выкупили и у меня эта задача ушла... Теперь в целях саморазвития думаю/читаю.изучаю "как надо". Так вот. Все течет все изменяется. Как грамотнее и более гибко работать с версиями АПИ. Версию АПИ с которой работает клиент мне показалось самым удачным передавать в заголовке запроса. Тут не определился: использовать "Accept' или вообще свой специальный. А дальше что? Вот тут я "завис". Пока видится такая схема: Роутер читает версию (если не передана, то текущая стабильная), определяет Контролер и метод...При этом... Предположим обратились к методу запроса некоего списка list контролера main. Т.е., по сути, вызываем Main::list(). Роутер обращается к статическому методу контролера "Дай мне имя метода для версии такой-то".... В роутере, при глобальных изменениях. Старый метод называем, например, listV1() и объявляем depricated. А актуальный метод всегда list(). Естественно, при обращении клиента с версией для которой поддержка прекращена возвращать ошибку. Так же буду благодарен если поделитесь ссылками на действительно толковые статьи по теме. (А не 'позавчера прочел "PHP за 24 часа" - вчера погуглил про REST API - сегодня написал статью "от гуру"') --- Добавлено --- Или, возможно, лучше даже так. В каталоге src подкаталоги по версиям. Полностью все файлы. И еще один "каталог" current (являющийся ссылкой на текущую стабильную версию)... Но тогда, вроде как, надо в функцию автозагрузки классов. вводить информацию о запрошенной версии.....
Можно в namespace включить версию, если надо, чтоб одновременно несколько версий работало, и динамически формировать имя контроллера Но, эм, у тебя же от версии к версии наверное сторона базы тоже меняется, и код старой версии не будет работать с новой базой
Эту сторону [про различие базы] предлагаю не рассматривать в данной теме (скорее всего придется вводить некий прокси, но это уже другая тема) Если в неймспейс передавать версию, то при смене версии придется пробегаться по всем файлам. Поэтому я подумывал передавать значение необходимой версии в автозагрузчик классов. Звучит не кошерно, зато неймспейсы прежние. А пути разные....
@voral, если есть необходимость поддерживать несколько версий, можно их закладывать в Namespace с самого начала, чтобы не пробегаться. Мне как-то махинации с автозагрузчиком меньше нравятся, хотя моё ИМХО, конечно.
А как не пробегаться.. Допустим имеем среди прочих 100500 файлов файл с описанием класса Main. У него namespace (с учетом версии ), например: Voral\v1\Controller. Создаем новую версию. Т.е. "копируем" весь каталог v1 в каталог v2 вносим наши супер изменения. И во всех файлах надо же поменять namespace: заменить v1 на v2 ?
А так делаем примерно такой загрузчик PHP: class Autoloader { private static $version = 'current'; public static function setVersion($version) { // проверяем допустимость self::$version = $version; } public static function load($className) { // из имени класса с неймспейсом получаем // имя файла вставив после вендора версию } } --- Добавлено --- Тоже конечно так... Но.. Лень жеж и человеческий фактор....