假设我正在创建一个RESTful服务,用于处理我仓库的订单。以下是相关需求:
这种方法的问题在于客户账户管理员如何获取要与客户账户关联的用户ID。任何对 /users 的 GET 请求都将通过仅检索其客户帐户中的用户来进行过滤。但是,因为会员创建之前会创建用户,所以他们永远无法查看该用户。 我也考虑过只有两个端点来创建用户。
在这种情况下,我们仍然可以缓存子资源的GET响应,因为它们不会改变,除非对特定id的子资源进行POST或PATCH/DELETE操作。
这种方式似乎也适用于订单。管理员可以查看所有订单,即使它们在技术上属于某个客户。
我喜欢把根资源看作是子资源的视图,这样更容易基于URL进行授权,这个想法不错。
所以,我想问的真正问题是:
即使其中一个端点只是子资源的聚合视图,并且不允许通过该端点创建资源,拥有多个代表同一资源的端点是否会成为问题?
- 允许顾客创建账户
- 顾客管理员可以为他们办公室的其他用户创建账户
- 允许顾客用户创建订单
- 网站管理员可以创建和管理所有顾客账户
- 网站管理员可以创建和管理所有用户
- 网站管理员可以创建和管理所有订单
# 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思想。然而,我不确定如何处理用户端点。问题是,我希望客户管理员能够创建用户,这些用户可以使用他们的客户账户创建订单。客户管理员应该在哪里进行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进行授权,这个想法不错。
所以,我想问的真正问题是:
即使其中一个端点只是子资源的聚合视图,并且不允许通过该端点创建资源,拥有多个代表同一资源的端点是否会成为问题?