REST Комплексный доступ к ресурсам

Question

В последние несколько недель я сталкиваюсь с вещами, которые помогают мне лучше понять REST.

На работе у нас возникают проблемы с доступом к некоторым остальным api-ресурсам, который имеет довольно сложный доступ, поэтому мне было интересно, может ли кто-нибудь помочь мне понять, если / что мы делаем неправильно и как правильно поступить?

Итак, проблема в том, что у нас есть конечная точка для получения всех заказов. например / orders эта конечная точка имеет нумерацию страниц, фильтры и т. д., эта конечная точка получит список заказов.

У нас есть два основных типа пользователей (администратор и учетная запись).

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

Таким образом, по умолчанию пользователь аккаунта может видеть все размещенные им заказы. Они также смогут видеть любые заказы, которые у них есть для них. (поэтому это различие заключается в том, что заказы размещаются пользователем, но могут быть для другого. Например, я мог бы заказать что-то для другого пользователя).

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

Так что примером для всего этого будет: если вы являетесь администратором, вы видите все заказы по умолчанию, если вы являетесь пользователем учетной записи и имеете разрешения для филиала x и y, вы увидите все заказы для x & y, а также любые заказы, сделанные вами самостоятельно.

Не нарушен ли здесь дизайн домена? Это то, что мешает мне увидеть выполнимое решение?

Я немного искал контексты пользователей, чтобы можно было немного разделить некоторые проблемы. Например, разные пользователи по-разному видят разные ресурсы. Таким образом, чтобы не сделать один размер подходящим для всех решений (что это определенно), вы должны построить 3 apis. Если бы я это сделал, я бы точно мог отделить админа от аккаунта. Но я не знаю, что делать со сложностью аккаунтов.

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

Извините, если многое из этого напыщенное или не имеет смысла. Буду признателен за любую помощь, даже если это поможет мне выбрать правильный путь. Как я уже сказал, я пытался понять, как настроить REST, одновременно пытаясь забыть о базовой базе данных, но проблема как чокнутая, так как это ставит меня в тупик.

Answer 1

Если у вас есть доступ на уровне кода в конце «заказов». Тогда вы можете проектировать таким образом.

1. Сделать идентификатор пользователя обязательным для ввода в конце «Заказы». Поэтому всякий раз, когда какой-либо пользователь вызывает API, он должен сделать запрос с параметрами идентификатора пользователя.
2. Как только вы получите идентификатор пользователя в конце «заказов», проверьте авторизацию пользователя, например, является ли пользователь администратором или нет, и у пользователя есть доступ к какой ветви.
3. Теперь, ограничьте данные в ответ соответственно.

Необходимо внести изменения в конце «Заказы», ​​чтобы авторизоваться, отфильтровать данные и соответственно отправить ответ.

Answer 2

Я думаю, что вы смешиваете 2 важных аспекта: во-первых, это стиль, которому должен следовать ваш API, во-вторых, логика авторизации, которую вы хотите применить.

REST

Если вы хотите сначала создать согласованный, понятный и поддерживаемый API для отдыха, вам нужно понять свой домен.

Так что для вас Орден, который собирается использовать ваш API, - это вашкодовая база уникальна и может ли она быть или может быть разделена для уменьшения сложности, связывания и увеличения изоляции?

Если у вас есть единственное понимание Порядка, просто оставьте его как есть.

Авторизация

Правила авторизации являются еще одним примером бизнес-логики, и они часто могут меняться по мере развития бизнеса.Я предлагаю вам относиться к авторизации так же, как к любой другой логике, например, при расчете суммы заказа.Поэтому, если у вас есть сервисный уровень, создайте сервис авторизации, где вы проверяете, что пользователю разрешено видеть.Вы также можете сделать это в фильтре, чтобы перед возвратом списка заказов вы применяли правила безопасности и удаляли все заказы, которые пользователь не должен просматривать.Вам не нравится этот подход?Затем вам нужно переместить «фильтры авторизации» вниз по стеку, чтобы сам запрос принял это во внимание.Исходя из того, что вы сказали, есть различные аспекты, которые необходимо учитывать при выполнении GetOrderByUserID (x), если вы используете EF, вы можете сгенерировать фильтры авторизации в качестве лямбда-выражения и добавить его в предложение where, убедившись, что вы инеобходимые объединения, чтобы вы могли получить ответвление, учетные записи и т. д.

Заключение Вам решать, как ваша система должна обеспечивать безопасность, но если вы не признаете существованиеиз нескольких объектов домена Order, BranchOrder, DelegatedOrder, AccountOrder и т. д., в запросе не должно быть никаких доказательств безопасности, которая будет применяться впоследствии, единственное, что авторизация запроса REST должна содержать достаточно деталей, вероятно,в заголовках, чтобы определить, кто запрашивает ресурсы.Также обратите внимание, что даже если вы разбиваете свой доменный объект (Заказ) на более конкретные типы заказов, вам все равно придется применять безопасность, и, следовательно, вам все равно нужно будет создавать и поддерживать правила безопасности.

Вашвопрос достаточно широкий и содержит достаточно информации, чтобы дать вам подсказки; если вы хотите получить более конкретный ответ, вам также необходимо обновить свой вопрос, чтобы он был более конкретным.