REST API: разработка маршрутов на основе ролей - PullRequest
Новая
       35

REST API: разработка маршрутов на основе ролей

0 голосов
/ 06 июня 2018

В настоящее время я создаю CRUD для пользователей в моей системе, есть два типа пользователей (родительские пользователи и дочерние пользователи).Родительский пользователь может получить / обновить / удалить разрешения своих детей, поэтому я подумал создать следующие конечные точки на моем API:

GET / parent / {parentId} / childs / {childId} / permissions
PUT / parent / {parentId} / childs / {childId} / permissions
УДАЛИТЬ / parent / {parentId} / childs / {childId} / permissions / {allowId}

Но существует третий типпользователя (администратора), который может получать / обновлять / удалять разрешения любого пользователя, которого он хочет, поэтому я думал о создании другого набора конечных точек:

GET / users / {userId} / permissions
PUT/ users / {userId} / permissions
DELETE / users / {userId} / permissions / {grantId}

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

1 Ответ

0 голосов
/ 06 июня 2018

Я бы, вероятно, организовал его так, чтобы у вас были только конечные точки администратора, и использовал бы роль, чтобы определить, какие действия допустимы.Например, если мы смотрим на разрешения, родительский файл выдаст / user / {userid} / permissions / {licenseId}, где идентификатор пользователя и идентификатор разрешения соответствуют идентификатору их дочернего элемента.Если это так, вызов выполняется и возвращает 200. Однако, если они выдают эту команду для кого-то, кто не является их ребенком, он возвращает несанкционированный доступ.

Для разрешений я бы использовал механизм, подобный Javaвеб-токен, который передается конечной точке с каждым запросом.

...