我应该在RESTful服务中拥有资源的多个视图/端点吗？

Question

假设我正在创建一个RESTful服务来处理我在网上的仓库订单.

• 我想允许客户创建帐户
• 我希望客户管理员能够为其办公室中的其他用户创建帐户
• 我想允许客户用户创建订单
• 我希望网站管理员能够创建和管理所有客户帐户
• 我希望网站管理员能够创建和管理所有用户
• 我希望网站管理员能够创建和管理所有订单

鉴于这些要求.我最初的想法是以这种方式设计端点.

# to request a new customer account
/customers/request {POST}
# create and view customers - limited to admins
/customers {GET, POST}
# view customer info, update a customer
/customers/{customer_id} {GET, PATCH}
# create and view orders for a customer
/customers/{customer_id}/orders {GET, POST}
# view and update order for a customer
/customers/{customer_id}/orders/{order_id} {GET, PATCH}

我非常自信这些道路是有意义的,并遵循一般的宁静想法.但是,我不确定如何处理用户端点.问题是,我希望客户管理员能够创建可以使用其客户帐户创建订单的用户.客户管理员在哪里发布POST以实现此目的？我有几个想法.在这个答案之后,我想到了这一点.

# creation of users always done through this endpoint no matter what the
# authenticated user's role is
/users { GET, POST }
# associate user with customer
/customers/{customer_id}/user_memberships { GET, POST }

这种方法的问题是客户帐户的管理员如何获得与客户帐户关联的用户的ID.通过仅检索属于其客户帐户的用户来过滤/用户上的任何GET请求.但是,由于用户将在成员资格之前创建,因此他们永远无法查看用户.我还想知道只有两个端点来创建用户.

# create a user for a customer account
/customers/{customer_id}/users {GET, POST}
# root users endpoint only accessible to admins
/users {GET, POST}
# return same user
/users/1
/customers/{customer_id}/users/1

它基本上归结为使用客户URL前缀作为授权方式.让两个端点使另一个端点无效似乎有点奇怪.如果根端点只是子资源端点的视图怎么办？

# view all users in system - admin only
/users {GET}
# create & view admin users
/admin/users {GET, POST}
# create internal office users
/locations/{location_id}/users { GET, POST }
# create customer users
/customers/{customer_id}/users { GET, POST }

在这种情况下,我们仍然可以在子资源上缓存GET响应,因为它们不会更改,除非在子资源的特定id上有POST或PATCH/DELETE.

这种风格似乎对订单也有意义.管理员可以查看所有订单,即使它们在技术上属于客户.

# admin can view all orders
/orders?customer_id=1234
/orders

我有点像根资源的概念是子资源的视图,允许基于URL的更容易的授权.

所以,我想在所有这些之后,我真正的问题是:

是否有多个端点表示同一资源是一个问题,即使其中一个端点只是子资源的聚合视图并且不允许通过该端点创建资源？

Answer 1

您不应将 API 设计、REST 原则和授权需求混为一谈。您应该以如下方式设计您的 API：

• 便于使用
• 易于维护
• 容易理解

API 设计的 RESTful 方法试图解决这些不同的问题。RESTful 方法是关于识别您拥有的对象、它们的状态以及它们可能的转换。

这就是它停止的地方。现在，您想知道授权。您希望能够根据用户是谁（管理员、客户……）和目标资源是什么（客户记录……）来控制用户可以对给定记录执行的操作。

您需要做的是以松散耦合的方式在 REST API 之上部署授权框架。换句话说，您想要外部化授权。您绝对不想将授权直接构建到您的 API 中。想象一下，您突然有了新的授权规则/约束：您必须重新编码您的 API。这样做你会破坏所有的客户。这会导致糟糕的用户体验。

因此，我们已经确定您需要外部化授权。伟大的。有哪些不同的方法？这取决于您使用的语言和框架。

您可以使用：

• Java 中的 Spring 安全性
• PHP 中的 Yii
• Ruby 中的 CanCan
• ... 还有很多

您还可以实现自己的过滤器，例如在 REST 端点前面的 Java 中的 Servlet 过滤器。

最后，您可以转向基于 XACML 的成熟的基于属性的授权模型。有几种开源和供应商替代方案。如果您不熟悉基于属性的访问控制或 XACML，请查看以下链接：

• NIST 解释的 ABAC
• XACML

使用 XACML，您可以集中定义策略，例如：

• 管理员可以查看所有客户账户
• 管理员可以修改分配给他/她的客户帐户
• 客户只能查看和编辑自己的帐户

然后在授权服务（在 XACML 中称为策略决策点）中评估策略。授权服务公开了一个二进制授权 API，您的 API 可以调用它：用户 Alice 能否查看记录 foo？.

使用基于策略的外部化授权并使用 XACML，您可以实现业务逻辑（您的业务 API）和授权逻辑之间的松散耦合，您可以更轻松地维护和更新。