假设我正在创建一个RESTful服务，通过web为我的仓库处理订单。
- 我想允许客户创建帐户
- 我希望客户管理员能够在他们的办公室为其他用户创建帐户
- 我想允许客户用户创建订单
- 我希望网站管理员能够创建和管理所有客户帐户
- 我希望网站管理员能够创建和管理所有用户
- 我希望网站管理员能够创建和管理所有订单
给定这些要求。我最初的想法是以这种方式设计端点。
# 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。对/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 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进行授权。
所以，我想在所有这些之后，我真正的问题是：
即使其中一个端点只是子资源的聚合视图，并且不允许通过该端点创建资源，拥有代表同一资源的多个端点是否是一个问题？
您不应该将API的设计、REST原则和授权需求混合在一起。你应该设计你的API，使它：
- 易于使用
- 易于维护
- 易于理解
API设计的RESTful方法试图解决这些不同的问题。RESTful方法是关于识别您拥有的对象、它们的状态以及它们可能的转换。
这就是它停止的地方。现在，你想知道授权。您希望能够根据用户是谁(管理员、客户…)和目标资源是什么(客户记录…)来控制用户可以对给定记录做什么。
您需要做的是以一种松散耦合的方式在REST API之上部署一个授权框架。换句话说，您希望外部化授权。您肯定不想直接将授权构建到API中。想象一下，您突然有了新的授权规则/约束：您将不得不对API重新编码。这样做会破坏所有的客户。这将导致糟糕的用户体验。
因此，我们已经确定您需要将授权外部化。太棒了有什么不同的方法？这取决于您使用的语言和框架。
您可以使用：
- Java中的Spring Security
- PHP中的Yii
- Ruby中的CanCan
- 。。。还有更多
您还可以实现自己的过滤器，例如在REST端点前面用Java实现Servlet过滤器。
最后，您可以转向基于XACML的全面的基于属性的授权模型。有几种开源和供应商的替代方案。如果您不熟悉基于属性的访问控制或XACML，请查看以下链接：
- ABAC由NIST解释
- XACML
使用XACML，您可以集中定义策略，例如：
- 管理员可以查看所有客户帐户
- 管理员可以修改他/她分配给的客户帐户
- 客户只能查看和编辑自己的帐户
然后在授权服务中评估策略(在XACML中称为策略决策点)。授权服务公开了一个二进制授权API，您的API可以调用它：用户Alice可以查看记录foo吗。
使用基于策略的外部化授权并使用XACML，可以实现业务逻辑(业务API)与授权逻辑之间的松散耦合，从而更容易地维护和更新授权逻辑
根据我的理解，例如，你希望对于特定的customerId，你希望这个客户只查看其用户，而不能创建其用户，这只能由管理员创建，所以这也可以使用spring安全性来完成，这肯定会产生问题，所以你必须根据你的需求对客户进行分类。