Современная разработка требует качественных системных подходов к разработке HTTP API проекта. Начиная от примитивных jquery проектов, который использует ajax, заканчивая react приложениями которые в корне строятся на асинхронной модели работы. В идеале, все должно документироваться через OpenApi/Swagger контракты, чтобы можно было профессионально строить взаимодействие между front-end/back-end разработчиками и параллелить работу.
История
Bitrix изначально не предоставил инструментов для написания API в системе. В битрикс по умолчанию нет классического роутера и много лет не было контроллеров, вплоть до недавнего времени.
В долгие годы отсутствия контроллеров, разработчики-пользователи платформы Bitrix исхищрались костылями (в т.ч. и мы в самом начале) или что еще хуже — пользовались старым механизмом ajax который был в bitrix, более продвинутые делали свои разработки или интегрировали с классическими FW.
Bitrix old ajax
Всем слабонервным можно пропустить данный абзац, ибо жуть. Запрос делался на ту же страницу, на которой находится компонент, который его вызывал. Парсер битрикса подключал все компоненты до тех пор, пока не доходил до нужного. И после этого этот компонент сбрасывал буфер всей предыдущей работы и начинал новый вывод. Ужасный оверхед по ресурсам. Никогда не думайте пользоваться этим, это дитя нулевых.
Типовые костыли
Выглядят они примерно следующим образом
- В папку названной /ajax/ или т.п. клались файлики с названиями вроде
send-form.php, в которой инициилизировалось ядро битрикса и писался исполняемый код прямо в этом файле - Те кто чуть больше ценили порядок в коде — в этот файл подключали компонент который писали. Компонент причем мог сразу работать в двух режимах и была одна точка обработки логики
А еще лучше — внедрите на проект Laravel
Bitrix controllers
Данная разработка не документирована, у нас есть только внутренняя документация Bitrix, которой пользуется команда. Конечно, есть призрачный шанс, что она немного видоизменится, но шансы маленькие — т.к. для этого придется переписывать целый ряд модулей b24, которые уже используют этот механизм, поэтому мы считаем эту технологию достаточно стабильной.
Плюсы
- Нативный (доступный с 18.5+ версии)
- Удобные полноценные контроллеры (схожие как в современных фреймверках вроде Laravel/Symphony), со своими интересными наработками
- Тайпхинтинг и приведение типов на уровне параметров
- Нативные методы JS библиотеки для работы с роутером, инкапсулирующие отсутствие роутера за удобным интерфейсом и позволяющие работать с помощью промисов, которые уже прикрыты полифилами (можно быстро и без вебпака на старом стеке написать код).
Минусы
- отсутствие REST friendly роутера, вместо него страшноватый механизм передачи query параметров, впрочем, как упомянуто выше — это все инкапсулировано за интерфейсом JS библиотеки.
- Как следствие — невозможность задокументировать в виде OpenApi/Swagger
На данном этапе развития, рекомендуется использовать новые контроллеры как наиболее удачный механизм.
Неофициальная документация в этом репозитории.
FW integration
Мы нормально относимся к гибридам, когда Bitrix скрещивают с Laravel/Symphony, беря от каждой платформы лучшее.
Роутеры и контроллеры в Laravel — значительно облегчают написание API. Мы используем этот подход, в основном, только на очень крупных проектах, где это окупается. На рынке только единицы используют такой подход, из примеров лидеров рынка: Sibirix, Qsoft.
Плюсы
- fullREST friendly
- OpenApi/Swagger
- Удобство написания и инструментов
Минусы
- Необходимо затратить некоторое время для интеграции
Данный способ можно интегрировать на проекты только с согласования руководителя разработки.
@nextgen Bitrix controller + router
Мы обсуждаем вместе с командой разработки BitrixFW следующее поколение контроллеров которые будут взаимодействовать с нормальным роутером. В лучшем случае, уже осенью, на следующей партнерской конференции мы сможем увидеть их прототип. В изначальном виде обсуждалось, что к текущим контроллерам прикрутят нормальный роутер. Ждем.