Как оптимально получить меню в JSON?

Тип материала: 
Версия Drupal: 
Ключевые слова: 
Модули и темы: 
Пт, 24/03/2017 - 21:48

Решил изучить принципы построения сайтов по принципу headless-Drupal. Не могу понять, как лучше получить меню? Установил  rest_menu_items и  rest_menu_tree. Получил приблизительно такую картину:
меню
Смущает, что в первом варианте есть параметры
"meta_data":{"entity_id":"453"},"delete_route":{},"edit_route":{}},
вроде пустые, но закрадывается сомнение в безопасности.
Второй вариант почему-то возвращает не все пункты меню.
Третий вообще возвращает не пункты меню, а описание и название меню.

Думаю, я не первый задался этим вопросом, поэтому надеюсь, кто-нибудь поделится опытом.

ЗЫ: как вариант, подойдёт любой пример вменяемого сайта на headless-Drupal 8 - поковыряю его респонсы в девтузах, может пойму что-то))

0 Спасибо

Комментарии

Аватар пользователя gun_dose
4 months 1 день назад gun_dose #

Спасибо за ссылку, много интересного. Но у этого чувака в видосах на странице нет ни одной менюшки. Соответственно, по моему вопросу там ничего нет.

Если что, мне не надо рассказывать про роутинг. Мне нужно просто получить список ссылок меню.

0 Спасибо
Аватар пользователя multpix
4 months 1 день назад multpix #

тут тебе решать, насколько целесообразно в headless drupal использовать menu-ui
ладно бы данные, но меню то в апи зачем?

имхо.
ты ведь щелкаешь мышкой модель данных в дру (со всеми полями связями правами),
и для нее - строишь апи для фронта.
меню - это фронт, зачем там меню дру?

0 Спасибо
Аватар пользователя gun_dose
4 months 1 день назад gun_dose #

Ты предлагаешь захардкодить в шаблон все пункты меню? Или как?

0 Спасибо
Аватар пользователя gun_dose
4 months 1 день назад gun_dose #

Ну это же бред какой-то. Вот прикинь, есть навигационное меню с пунктами личный кабинет, мои заказы, справка, контакты. И вдруг надо туда впереть ссылку на страницу "публичная оферта". И что? Шаблоны править? Бред же. Так или иначе, список пунктов меню должен лежать в бэкэнде.

0 Спасибо
Аватар пользователя multpix
4 months 1 день назад multpix #
gun_dose написал:
Так или иначе, список пунктов меню должен лежать в бэкэнде.

вот опять "бред", "должен"...
это подход нуба, не инженера - ты пробуй, сравнивай, и бери оптимальный вариант)))

по мне - если разделяешь бек и фронт, начни с полного разделения.
иначе - ты себя просто изначально загоняешь в рамки.

0 Спасибо
Аватар пользователя gun_dose
4 months 1 день назад gun_dose #

И опять же, то, что я собираюсь делать, полностью соответствует правой картинке. Список ссылок меню - это данные. И рендерить их я буду на клиенте.

0 Спасибо
Аватар пользователя multpix
4 months 1 день назад multpix #
gun_dose написал:
Решил изучить принципы построения сайтов по принципу headless-Drupal

gun_dose написал:
Но у этого чувака в видосах на странице нет ни одной менюшки.

gun_dose написал:
Мне нужно просто получить список ссылок меню.

)))

и у этих, с json_api менюшек друпальных нет...
https://www.youtube.com/playlist?list=PLZOQ_ZMpYrZsyO-3IstImK1okrpfAjuMZ

Как же так!

0 Спасибо
Аватар пользователя ХулиGUN
4 months 1 день назад ХулиGUN #

Лясей, я понял суть проблемы))).
Смотри, есть несколько паттернов разработки ПО:
1. (Друпаловский) ТЗ->Функционал->Дизайн->Вёрстка
2. (Общепринятый) ТЗ->UI/UX->Дизайн->Вёрстка->Бек

И вот как раз в твоём случае названия ссылок меню, их наличие и последовательность это и есть дизайн. Если ты хочешь юзать друпал исключительно как бек с json сообщением, то ты и должен его юзать, как бек с json сообщением, а не делать на нём готовый сайт, а потом стараться его весь передать json`ом во фронт. Идиология самого реста исключает всякие меню и прочую шалупонь. Есть сущности, с которыми можно делать определённые действия. Есть понятия эндпоинта и важны заголовки запроса.
Простой пример. Есть сущности, например, статья (article) и коммент(comment), Есть некий сервак restserver.ru, который предоставляет API по урлу /api/v1/. Построение роутов максимально одинаково restserver.ru/api/v1/{endpoint}/?{pk} В случае со статьями карта роутов должна выглядеть примерно так:

GET         restserver.ru/api/v1/article        - получение всех статей(через гет параметры возможна пагинация и фильтрование)
GET         restserver.ru/api/v1/article/32   - получение конкретной статьи с id 32
POST      restserver.ru/api/v1/article        - создание новой статьи
PUT         restserver.ru/api/v1/article/32   - обновление статьи с id 32
DELETE  restserver.ru/api/v1/article/32   - удаление статьи с id 32

И ни о каких меню и навигации на стороне этого сервера и быть не может. Навигация должна относится к фронту и решаться на его уровне и опрашивать бек для этого как минимум глупо. Если такое делается, значит как минимум нет дизайна и UI\UX, а значит нет пользовательских интерфейсов и фронта для этих интерфейсов

Вернёмся к паттернам. В общепринятом случае на первом этапе делаются макеты интерфейсов и прорабатывается взаимодействие пользователя с этими интерфейсами, затем разукрашивается, чтобы клиент мог посмотреть как будет выглядеть его будущий сайт внешне. Затем это всё верстается(Красивые картинки -> html, js, css). И только потом приступает к работе бек, чтобы исходя из интерфейсов грамотно составить архитектуру и заменить всю "рыбу" динамическими данными. В твоём случае ты делаешь всё с точностью до наоборот

1 Спасибо
Аватар пользователя multpix
4 months 18 часов назад multpix #

api вообще не должна кандубасить маршрутизация фронт,
фронту пох что думает api о его маршрутизации

0 Спасибо
Аватар пользователя BatKor
1 month 2 недели назад BatKor #

Хотел задать вопрос, но пока писал понял.

0 Спасибо
Аватар пользователя gun_dose
1 month 2 недели назад gun_dose #

И что же именно ты понял?))

0 Спасибо
Аватар пользователя BatKor
1 month 2 недели назад BatKor #

Да появился тот же вопрос, как мне получать список меню. Но после комментов x..лиgаna, осознание прочтённого пришло с задержкой:-)

1 Спасибо
Аватар пользователя gun_dose
1 month 2 недели назад gun_dose #

Я тебе по секрету скажу, что хулиган и мультпикс по этой теме дальше хэллоуорлда не зашли))

0 Спасибо
Аватар пользователя multpix
1 month 2 недели назад multpix #

ээ..
дажи хелоуорда не было))))

0 Спасибо
Аватар пользователя gun_dose
1 month 2 недели назад gun_dose #

Тем более))

0 Спасибо
Аватар пользователя ХулиGUN
1 month 2 недели назад ХулиGUN #
gun_dose написал:
Я тебе по секрету скажу, что хулиган и мультпикс по этой теме дальше хэллоуорлда не зашли))

Болтун - находка для шпиона.)))
Ты хоть сам сам осознал, где был не прав?

0 Спасибо
Аватар пользователя gun_dose
1 month 2 недели назад gun_dose #

Представь себе, я до сих пор на 100 процентов уверен, что я прав.

0 Спасибо
Аватар пользователя multpix
1 month 2 недели назад multpix #

со временем все поймешь, не торопи события)))

0 Спасибо
Аватар пользователя ХулиGUN
1 month 2 недели назад ХулиGUN #
gun_dose написал:
Представь себе, я до сих пор на 100 процентов уверен, что я прав.

У тебя бек и фронт - 2 абсолютно независимых приложения. Ты ведь сам так решил, ещё в начале

gun_dose написал:
И опять же, то, что я собираюсь делать, полностью соответствует правой картинке.

А поэтому бек не может УПРАВЛЯТЬ фронтом, он может только давать данные, которые попросит фронт.
Ты, как автор сяго чуда вправе определить дополнительные методы, которые вернут тебе то, что ты хочешь, но это не будет вписываться в общий концепт реста. Изначально сущности сайта это Юзеры, ноды, комменты и таксономия. Всё остальное - вьюхи, меню, etc это админский функционал БЕКА и к фронту никаким боком

0 Спасибо
Аватар пользователя multpix
1 month 2 недели назад multpix #

суть в том, что друпаловские сервисы это далеко не единственный, и уж точно не самый лучший способ организовать данные и апи для доступа к ним.
это просто возможность - сделать бек на дру? да - можно.
нужно как минимум попробовать что-то иное, чтоб знать, чего вообще хотеть))))

0 Спасибо
Аватар пользователя gun_dose
1 month 2 недели назад gun_dose #

Суть в том, что для несферических ситуаций любые готовые решения ведут к ограничениям и проблемам. Классический REST-подход (один эндпоинт - один тип данных) ведёт к большой связности кода. В JSON-API - есть свои ограничения - он не умеет собирать обратные референсы и не умеет делать агрегацию. Естественно, я сейчас не про друпал, а вообще. Надо ещё посмотреть GraphQL - если он умеет обратные референсы и агрегации, то можно смело отказываться от всех остальных методик, хотя думаю вряд ли. И придётся по-прежнему лепить приложения из всего подряд.

0 Спасибо
Аватар пользователя gun_dose
1 month 2 недели назад gun_dose #
ХоолиGUN написал:
А поэтому бек не может УПРАВЛЯТЬ фронтом, он может только давать данные, которые попросит фронт.

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

ХоолиGUN написал:
Изначально сущности сайта это Юзеры, ноды, комменты и таксономия

Сущности да. Но не едиными сущностями живут приложения. Помимо сущностей есть ещё действия, права доступа и информация о структуре сущностей, необходимая для генерации форм создания и редактирования тех же сущностей.

0 Спасибо