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

假设我正在创建一个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的更容易的授权.

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

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