29 июля 2019 в 14:57
Всем привет!
Подскажите пожалуйста, кто-нибудь сталкивался с задачей, что Drupal оперирует данными не из базы (нодами), а с json'ами.
Суть в том, чтобы с интегрироваться с другой системой через апи, а в качестве интерфейса и админки присоединить Drupal.
Т.е. задача такая, сделать гет запрос на некий урл, получить json, и отобразить его как ноду, затем опять же как ноду можно отредактировать, потом упаковать в json и отправить обратно. И так построить всё общение.
Комментарии
В подобных системах друпал обычно выступает в качестве API а не интерфейса, а вы хотите всё сделать наоборот. Моё мнение - друпал тут будет вообще лишний. Всё, что вам нужно - это какой-нибудь js-фреймворк.
Спасибо за ответ! На самом деле уже решали похожую задачу, как раз за интерфейс брали angularjs. Но тут увы нужно через Drupal построить общение.
А в чем именно проблема?
Вообще, принято не "тупо отображать данные с API", а кешировать их в каком-то виде, чтоб не сильно зависеть от стороннего сервера.
Но, если и так, просто - определяете динамический роут, и в зависимости от этой динамики - хендлите запрос, вытягивая, обрабатывая и выводя данные на страницу, в необходимом виде.
Спасибо!
Самой проблемы как таковой ещё нет) Просто хотел узнать кто как реализовывал, если сталкивался.
Guzzle + json_decode. Дальше бизнес-логика.
Тут никто ничего не подскажет, т.к. все чуть менее чем полностью зависит от задачи.
сейчас по долгу службы часто сталкиваюсь с подобными задачами, например прикрутить GeoIP или интегрировать с AmoCRM.
Но тут подход похожий, только данные отображаем в виде контента на странице, а не в блоке. Плюс можно закэшировать в базу, чтобы не насиловать стороннее API
Наверное Вы про это: https://www.drupal.org/project/external_entitiesn ??
Извиняюсь, ссылка "битая", так лучше: https://www.drupal.org/project/external_entities
там как раз реализован кастомный "слой" EntityStorage, для работы с удаленным стореждем как с "родным".
"Изучал" код этого модуля для решения подобной задачи.
Если удалённый сервер не посылает запрос сам при обновлении данных, то в случае кэширования ответа можно столкнуться с перманентно устаревшими данными.
Натянуть стороннюю структуру данных на систему сущностей, как советовали выше, может оказаться крайне сложно. Хотя если есть уверенность, что сможешь сделать свою имплементацию EntityStorage, то можно попытаться. С полями будет два варианта: либо хардкодить их в baseFieldDefinitions, либо писать плагины под каждый возможный тип поля, хранящегося в API.
Если же делать тупо на формах, то это будет сплошная боль, если нужны формы со сложным UX.
Есть ещё способ: просто собрать всё на обычных сущностях, пусть даже на нодах и отправлять изменения в API по hook_node_update. Но в таком случае нужно продумать, как забирать данные с API, чтобы они не успевали устареть.
Узкое место - получение сигнала о о том, что данные изменились на стороннем ресурсе, если он дергает триггер который Вы периодически слушаете то эта одна ситуация а если нет, то Вам нужно опрашивать много чего разного другого.