Антология построения REST запросов внутри MODX - мой опыт

Это вводная статья для серии публикаций, посвященного удобному построению полноценного RESTfull API для любых целей.



Вообще на заре моей карьеры в MODX ни о каких REST запросах не было и речи. Или я в силу отсутствия опыта просто не замечал такой темы. В основном мы говорили о том, как отправить произвольный ajax запрос. Как мы только не изворачивались для того, чтобы сделать ajax запрос и получить ответ.

Сниппеты и файлы

Сначала популярным (почему-то) вариантом было создание отдельного ресурса с пустым шаблоном и вызовом в контенте сниппета ajax. Некоторые особо умные создавали по несколько страниц, и дублировали сниппеты, чтобы они обрабатывали разные запросы. Я до сих пор встречаю такие сайты. Вот в этом году уже попадался. Да что греха таить — у меня у самого есть ныне действующий сайт, сделанный 6 лет назад. Я его не трогаю по принципу — работает и ладно. Там до сих пор есть страничка ajax.html

Самые продвинутые писали отдельные PHP файлы и направляли запрос на них, разруливая всю логику внутри. Этот способ до сих пор вполне себе неплох для короткой логики, которую легко прочитать.

Оба варианта работали только с двумя видами HTTP запросов. GET и POST.

Плагины и компоненты

Со временем мы научились писать плагины, срабатывающие на событие onHandleRequest, принимать в них action, при помощи которого опознавали запрос и либо обрабатывали его сразу на месте, либо дергали нужный класс-обработчик
Такой способ обработки запросов и сейчас актуален. Единственный минус в необходимости создания плагинов в базе данных. Если придерживаться SOLID принципа — то выходит что на каждый запрос должен быть свой плагин. А для больших проектов — это ой как накладно.

Родной REST API

Он как то сразу не зашел. Имел ряд недостатков, сложен для понимания. Лично мне не понравился ровно по той, же причине, что и родные процессоры. Вынуждает наследовать родные, мягко говоря не современные классы MODX. Внутри придерживаться довольно жестких структурных правил, работать с конкретным объектом. А еще проблема была в том, что на одну сущность, можно было назначить только один контроллер, который вынужден был обрабатывать все возможные виды HTTP запросов. Это неправильно. На каждый метод, даже для одной сущности должен быть свой отдельный контроллер.

ZoomX

Да данный момент это наиболее простой, удобный и современный способ построить RESTfull API с возможностями, гораздо более широкими возможностями чем у родного modRestService.

В последующей серии публикаций мы попробуем разобраться почему же так хорош ZoomX и как им вообще пользоваться.

Мы шаг за шагом решим несколько практических задач и затем перейдем к более комплексному практическому курсу по построению API для интернет-магазина и работа с сайтом без браузера. Построим современный (в рамках MODX) Headless сервис, работая вообще без админки.

Зачем вообще использовать MODX если все равно писать всю логику в контроллерах внутри IDE

Почти в любой беседе, при упоминании современной разработки, с использованием фреймворков возникает популярное возражение — зачем вообще использовать MODX, если на разработку правильной удобной для разработчика системы нужно потратить столько же сил и знаний, сколько в Laravel. Ответ очень простой — у нас по-прежнему остается возможность использовать знакомые, готовые компоненты, вроде pdoTools, minishop, по-прежнему остается готовая админка, которой нет во laravel.