Максим

1. Если у вас есть доступ к беку, то вам лучше ошибки переводить на нем. Отображение ошибки в зависимости от локали. Переводить лучше тут, так как клиентов вашего api может быть много и будет очень странно если одна и та же ошибка на web будет переведена не так, как в mobile.
2. Если у вас доступа к беку нет, то я бы на уровне ApiClient сделал обработку и перевод всех ошибок в одном месте. Например, axios может сделать это в одном месте.

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

Кроме обработки статуса ответа можно ещё и смотреть на код ответа, как написали в соседнем ответе. Коды ответов не всегда удобны для простой разработки. Так как требуют дополнительной разработки со стороны api и дополнительной обработки со стороны клиента.

1. Работу с request используют высокоуровневые вещи вроде контроллеров, поэтому использовать их в своих сервисах не стоит. Ваш сервис это по сути слой связи приложения и вашего кода. Поэтому правильней всего переложить данные из request в какую-то DTO например из патерна CQRS это может быть Command(), Query()

2. Даже когда вам потребуется передавать Request в какие-то свои классы, то лучше для этого использовать PSR интерфейсы. Тогда ваш Request будет фреймворконезависимым. .

Очень сложных проектов на Yii2 с открытым, да ещё и хорошим кодом очень мало)) Прежде всего, потому что Yii создан для быстрой разработки нарушая все правила сложных архитектур. А учитывая его устарелость, то тем более таких проектов мало. На форуме давно обсуждался этот вопрос. Там есть ссылки на проекты и код. Так же на сайте yiipowered.com есть список проектов, у некоторых с исходным кодом.

Вам лучше изменить тактику и искать проекты с хорошей архитектурой вне зависимости от фреймворка. Так ваша вероятность найти что-то стоящее на много выше. В целом, хорошая архитектура - это всегда дорого. Мало кто будет выкладывать проект большой команды, на которую были потрачены сотни тысяч и миллионы в открытый доступ. Кроме того хорошая архитектура всегда зависит от требований, задач и самого проекта. Что и где применять, как строить - придет только со знанием и опытом. Здесь не получится сделать по примеру.

Если по теме, то начните изучать или искать DDD, CQRS, SOA, Микросервисы. В принципе это основные архитектурные подходы в разработке. На Yii по DDD есть хороший пример. Однако начинать НОВЫЙ проект на Yii2 используя даже самую сложную архитектуру - путь в никуда. Yii2 создан для других целей. Чтобы понять можно посмотреть ответ на вопрос: Актуален ли Yii2 Фреймворк в 2020?

Создайте дополнительное поле json и туда сохраняйте состояние текущих полей, версию или просто дату создания. При модификации добавляете в массив новые данные. При откате просто заменяете текущие данные на данные из версии. Но это такое себе решение)

Вот более подробно. https://m.habr.com/ru/post/101544/

Это если просто. Мои мысли такие. Вообще, лучше добавить другие теги и может ещё что подскажут. Это не совсем про Yii