Готовим версионирование API в PHP-фреймворках: разбор способов и работа с организацией кода

Вопрос к разделу об организации кода.

Т.е. даже если мы меняем один метод в одном контроллере мы должны прицепом скопировать все остальные контроллеры без изменений?

Всегда это казалось каким то оверхедом... может для этой цели использовать схемы API Gateway и описывать только изменённые пути, а остальные направлять на предыдущую версию, которая в свою очередь на другую вплоть до 1 версии

Особенность проекта в том, что бэкенд деплоился достаточно быстро, это занимало минуту‑полторы, а с фронтендом было сложнее, он деплоился долго — 10–15 минут.

А есть еще база данных, которая может мигрировать (даже если все без ошибок) часами...

К пункту Явное указание версии в пути. на случай если в пути не указана версия, считать это актуальной стабильной версией. А в файловой системе это определять симлинком. Конечно если это позволяет проект.

Хорошая статья! Хотелось бы отметить, что на практике порой большей проблемой является попытка совместить бизнес-логику разных версий API.

Классический пример. Есть crud-набор API-методов работы с пользователями. У пользователей есть поле phone. Делаем фичу, чтобы пользователи могли указывать несколько телефонов. В новой версии API или в текущей же вводим поле-коллекцию phones. И возникает вопрос, что делать, когда через старую версию API редактируют пользователя, передавая новый телефон в phone, когда в базе у редактируемого пользователя уже лежит несколько телефонов, установленных ранее через новую версию API.

На первом скрине код интересный. Второе условие когда-нибудь выполнялось?

Подскажите, пожалуйста, а когда в uri указывает версию апи то там полностью по semver надо указывать?