rest - 我应该在 RESTful 服务中拥有多个资源 View /端点吗？

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}

我非常有信心，这些路径是有意义的，并遵循一般 Restful 想法。但是，我不确定如何处理用户端点。问题是，我希望客户管理员能够创建可以使用其客户帐户创建订单的用户。客户管理员在哪里发布帖子以完成此操作？我有几个想法。
关注此 answer ，我想过这个。

# 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。/users 上的任何 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 怎么办？

# 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

我有点喜欢根资源是子资源 View 的想法，允许基于 url 进行更轻松的授权。

所以，我想毕竟，我真正的问题是:

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

Answer 1

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

易于使用

易于维护

通俗易懂

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

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

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

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

您可以使用:

Java 中的 Spring Security

PHP 中的 Yii

Ruby 中的 CanCan

... 以及更多

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

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

ABAC explained by NIST

XACML

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

管理员可以查看所有客户账户

管理员可以修改分配给他/她的客户帐户

客户只能查看和编辑自己的帐户

然后在授权服务(在 XACML 中称为策略决策点)中评估策略。授权服务公开了一个二进制授权 API，您的 API 可以调用该 API:用户 Alice 是否可以查看记录 foo?。

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