Процессоры в RESTful API: использовать нельзя выбросить

При планировании разработки механизма RESTful API была идея использовать стандартные процессоры. Плюсы очевидны — готовый код для CRUD с проверками прав и лексиконами. Кроме того, более простая интеграция с дополнениями. Ведь они тоже работают через процессоры. Т.е. их серверную часть переписывать не нужно. По крайней мере, не всю.

Что смущает?

В некоторых базовых и пользовательских процессорах заложена специфика ExtJs. Не критично, но загрязняет код.

Ответ кодируется в JSON со своим форматом. А значит его нужно раскодировать. Получается двойная работа: массив -> json -> массив.

В работе процессора заложено множество проверок с выводом ошибок — проверка прав доступа, beforeQuery(), beforeSave(),saveObject(), beforeRemove(), обработка результатов работы плагинов и т.д. И все они выводят просто сообщение без кода ошибки. Т.е. нельзя отличить ошибку «Permission denied», у которой код 403, от любой другой четырёхсотой.

Механизм процессоров, насколько я могу судить, в двойке и тройке отличаются. Т.е. данный компонент будет зависеть от версии. Хоть я и не верю в выход третьей версии, всё же я не отрицаю тот факт, что это не зависит от моей позиции. Поэтому нужно универсальное решение. Не увидел отличий.

Ну и наконец, сам код, который безумно далёк от современных стандартов. А местами и попахивает.

Это из того, что лежит на поверхности. Уверен, дальше возникнут ещё моменты. Но главный вопрос следующий — стоит ли всё-таки использовать процессоры? С одной стороны плюсы сильно сокращают количество работы. С другой — решение будет не полностью соответствовать стандартам PSR и JSON:API. Ну и полностью не соответствовать главной идее — максимально дистанцироваться от ядра, чтобы не зависеть от «хозяев» MODX.

Ох, как сейчас не хватает голосовалки. В общем, попробую сформулировать вопросы:

1. Использовать процессоры как есть.
2. Писать свои процессоры на основе modProcessor.
3. Вообще не использовать механизм процессоров. Писать свой механизм по стандартам PSR с использованием шаблонов проектирования.
4. Хозяин — барин. Делай как считаешь нужным.

Так как цель написания данного дополнения выходит за рамки ещё одного плюсика в репозитории MODX, то очень нужно услышать коллективное мнение.