Как смоделировать ограничения на данные, видимые на ресурсах? - PullRequest
1 голос
/ 10 февраля 2012

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

Дело, над которым я работаю:
Решение без ограничения доступа к информации:

User:
  name
  phoneNumber

Если бы кто-нибудь мог получить к нему доступ, это было бы легко смоделировать как:

GET /User -> [{name:"John", phoneNumber: "322-333"}]
GET /User/{id} -> {name:"John", phoneNumber: "322-333"}

Однако, скажем, у меня две роли: администратор и пользователь.PhoneNumber должен быть виден только пользователям, которые также являются администраторами.Токен авторизации передается в файле cookie, заголовке или подобном.Сервер будет знать, какие роли имеет запрашивающая сторона.Как разработать API для этого?У меня есть пара идей:

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

If user: GET /User -> [{name:"John"}]
If admin: GET /User -> [{name:"John", phoneNumber: "322-333"}]

2) Вставитьроль в URL:

If user is wanted as a User: GET /User/User -> [{name:"John"}]
If user is wanted as an Admin: GET /Admin/User -> [{name:"John", phoneNumber: "322-333"}]

3) Определите новый ресурс для каждого возможного подмножества полей:

If user is wanted as a User:   GET /PublicUserInfo -> [{name:"John"}]
If user is wanted as an Admin: GET /FullUserInfo -> [{name:"John", phoneNumber: "322-333"}]

Будет ли другой подход лучше?
У кого-нибудь естьопыт работы с решением, которое сработало на практике?

1 Ответ

0 голосов
/ 10 февраля 2012

Используйте опцию 1 на основе аутентифицированного пользователя. Если вы выбираете 2 или 3 клиентов, реализующих ваш API, вам придется в два раза больше беспокоиться о конечных точках API и о том, когда их следует использовать.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...