ExpressJS - RESTful дизайн маршрута для вложенных / связанных ресурсов - PullRequest
0 голосов
/ 13 февраля 2019

Это общий вопрос о проектировании маршрутов RESTful для связанных / вложенных ресурсов на примере ExpressJS с MongoDB. В итоге, как мне спроектировать такие вложенные / связанные маршруты?

О моем приложении / сценарии: у меня есть служба RESTful, реализованная с NodeJS / ExpressJS и MongoDB .У меня есть две разные связанные модели Category и Article.

const mongoose = require('mongoose');

const article = new mongoose.Schema({

    title: {

        type: String,
        required: true
    },
    body: {

        type: String,
        required: true
    },
    category: {

        type: mongoose.Types.ObjectId,
        ref: 'Category',
        required: true
    }
});

const category = new mongoose.Schema({

    name: {

        type: String,
        required: true
    }
});

Я нашел два способа спроектировать корабль отношений соответственно маршрутам:

Ориентированные на отношения

Это означает, что используются вложенные пути и связь прямолинейна /api/categories/:category/articles/:article.

Преимущество в том, что установить категорию статьи очень просто, поскольку ее можно предварительно загрузить с помощью идентификатор пути param (: category) с промежуточным программным обеспечением Express.

router.post('/', (request, response, next) => {

    let article = new Article(request.body);

    article.category = request.category; // Preloaded category

    ...
});

Недостаток в том, что действительно трудно получить все статьи конкретным пользователем, потому что с этим дизайном вы получаететолько все статьи для одной категории.Например, /api/categories/1/articles вы получаете только статьи для первой категории, поэтому, если вы отфильтруете запросы для примера ?user=5, вы найдете только статьи пользователя 5 для категории 1, но не все статей пользователя 5.

Ориентированность на доступность

Это означает, что нет глубоких вложенных маршрутов и отдельных «конечных точек» для каждого ресурса /api/categories/:category И /api/articles/:article.

Преимуществоэто то, что теперь очень легко фильтровать по очень разнообразным свойствам и условиям, таким как ?user=5 или ?title=Works.

Большим недостатком является то, что теперь я не могу просто использовать идентификатор параметра пути для категории, потому что онне существуетСредства, которые пользователь должен указать внутри тела запроса категории.Существуют ли лучшие практики для реализации этого?

Какой дизайн вы бы предпочли, и есть ли какие-либо лучшие практики для устранения недостатков?

РЕДАКТИРОВАТЬ

Я забыл указать, что нашел эту статью , но она, похоже, не имеет отношения к упомянутым недостаткам.Я очень заинтересован в подходах к их решению.

1 Ответ

0 голосов
/ 13 февраля 2019

Если я вас правильно понимаю, вы можете рассмотреть следующие маршруты:

  • /categories: список всех категорий
  • /categories/:categoryId: если вы решили составить списоккатегории скудные, это может предоставить дополнительную информацию о одна категория
  • /categories/:categoryId/users Все пользователи с данной категорией
  • /categories/:categoryId/users?gender=M Все пользователи мужского пола в данной категории
  • /articles Список всех статей
  • /articles/:articleId Список дополнительных сведений об идентификаторе статьи

Ознакомьтесь с Наименование ресурса здесь

Идея такова: если вам нужны более подробные сведения, например, /categories/:categoryId, а мне нужны только пользователи, я могу определить маршрут как categories/:categoryId?select=users

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

...