REST 复杂资源访问

Question

所以我在过去几周遇到了一些事情，这让我提高了对 REST 的理解。

在工作中，我们遇到了一些 rest api 资源访问问题，这些资源访问具有一些非常复杂的访问权限，所以我想知道是否有人可以帮助我了解我们是否/什么做错了，以及正确的方法是什么。

所以我们遇到的问题是我们有一个用于获取所有订单的端点。例如/orders 这个端点有分页和过滤器等，这个端点会得到一个订单列表。

我们有两种主要类型的用户（管理员和帐户）。

如果您是管理员，则可以查看所有订单，如果您是帐户用户，则有点棘手，因为帐户用户可以根据一组权限查看订单。

因此，默认情况下，帐户用户可以查看他们已下的所有订单。他们还可以看到他们有的任何订单。 （所以这里的区别是订单是由一个用户下的，但可以是另一个用户。例如，我可能会为另一个用户订购东西）。

由于应用程序的设计方式，用户也可以看到其他分支机构的订单，例如一个分支机构报告者，它处理来自所有分支机构的订单并整理报告等。

所以所有这一切的一个例子是： 如果您是管理员，则默认查看所有订单；如果您是帐户用户，并且拥有分支 x 和 y 的权限，您将看到 x 和 y 的所有订单以及您自己下的任何订单。

这里的域设计有问题吗，是什么阻止我看到可行的解决方案？

我一直在研究用户上下文，所以这可能是一种解决一些问题的方法。例如，不同的用户以不同的方式查看不同的资源。因此，要不制作一个适合所有解决方案（这绝对是），您应该构建 3 个 api。如果我这样做了，我绝对可以将管理员与帐户分开。但我不知道如何处理帐户的复杂性。

我怀疑这与删除从数据库中签出的这些权限并将它们移入权限有关，但我不确定如何处理动态权限。

很抱歉，如果其中很多内容是咆哮或者这没有意义。即使只是为了让我走上正确的道路，任何帮助都将不胜感激。 就像我说的那样，我一直在尝试了解如何配置 REST，同时试图忘记底层数据库，但是像这样的问题让我很困惑。

Answer 1

我认为您混合了两个重要方面，第一个是您希望 API 遵循的样式，第二个是您要应用的授权逻辑。

休息

如果你想构建一个一致、清晰、可维护的REST API，首先你需要了解你的领域。

那么对于您来说什么是订单，谁将使用您的 API，您的代码库是唯一的吗？必须如此，还是可以拆分以降低复杂性、耦合和增加隔离？

如果您对 Order 有一个单一的理解，请保持原样。

授权

授权规则只是业务逻辑的另一个示例，随着业务的发展，这通常会发生变化。 我建议您像对待任何其他逻辑一样对待授权，例如计算订单总额时。 因此，如果您有一个服务层，请创建一个授权服务，您可以在其中检查允许用户查看的内容。 您也可以在过滤器中执行此操作，以便在返回订单列表之前应用安全规则并删除用户不应查看的所有订单。 你不喜欢这种方法吗？然后，您需要将“授权过滤器”移到堆栈中，以便查询本身将其考虑在内。 根据您所说的，在执行 GetOrderByUserID(x) 时需要考虑各个方面，如果您使用 EF，则可以将授权过滤器生成为 lambda 表达式，您可以将其添加到 where 子句中，确保您和必要的联接，以便您可以获取分支、帐户等。

结论 这取决于您希望您的系统如何实现安全性，但除非您认识到存在多个域对象 Order、BranchOrder、DelegatedOrder、AccountOrder 等，否则在请求中不应该有安全性的证据之后应用，唯一的事情是 REST 请求的授权必须携带足够的细节，可能在标头中，以识别谁在请求资源。 另请注意，即使您将域对象（订单）分解为更具体的订单类型，您仍然需要应用安全性，因此您仍然需要创建和维护安全性规则。

您的问题有点宽泛，只有足够的信息给您提示，如果您想要更具体的答案，您需要更新您的问题以更具体。

Answer 2

如果您在“订单”结束时具有代码级访问权限。那你就可以这样设计了。

1. 在“订单”端将用户 ID 作为强制性输入。所以当任何用户调用 API 时，他都应该使用 User ID 的参数发出请求。
2. 在“订单”端获取用户ID后，检查用户的权限，例如用户是否为管理员，用户可以访问哪个分支。
3. 现在，相应地限制响应数据。

您应该在“订单”端进行更改以授权、过滤数据并相应地发送响应。