Веб-приложение (API и Front-end) - дизайн маршрутов

Question

Я предполагаю, что этот тип тем всегда существует, но мне нравится иметь конкретное мнение для моего случая.Уже полтора месяца я думаю о создании веб-приложения для листинга для моей повседневной жизни (покупка, оплата и т. Д.). Я начал определять свою объектную модель следующим образом (очень простая модель проектирования)

Models image

Итак, я решил создать NodeJS API для back-end и Angular 7 для front-end.Для меня это не техническая проблема при разработке приложения и API, но моя проблема заключается в разработке этого и, в частности, в разработке маршрутов.

Мое первое предложение по API маршрутов: Пользователь:

• / пользователи
• / пользователи /: id

Список:

• / списки
• / списки /: id

Элемент:

• / elements
• / elements /: id

Технически это нормально, но я не уверен, что это хорошая практика.Так как Пользователь содержит Список, а Список содержит Элемент, не было бы лучше иметь такие маршруты:

• / users /: id
• / users /: id / list
• / users /: id / list /: id
• / users /: id / list /:id / element
• / users /: id / list /: id / element /: id

Спасибо за ваши ответы или предложения!

PS: Если у вас есть какие-либо веб-сайты / видео / темы ... чтобы предложить, не стесняйтесь.

Answer 1

Во-первых, вы находитесь на абсолютно правильном пути определения маршрутов в углах, в то же время вы должны использовать Ленивая загрузка Концепция маршрутизации.

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

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

Надеюсь, это поможет.,

Answer 2

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

Что вы можете сделатьнайти простые отношения, например:

• / users /: id / lists
• / lists /: id / elements

Я бы порекомендовал прочитать сборку apis, которую вы не будете ненавидеть :)