Restful API 设计：用户端点和权限端点应该如何设计？

Question

基于类似的问题，我得出的结论是，设计此端点以获取 GET 请求的最方便的方法应该类似于：

GET /v3/users/
GET /v3/users/{userId}
GET /v3/users/{userId}/authorities
GET /v3/users/authorities/{authId}

我的问题是下一个端点应该如何：

1. Create authorities
POST /v3/users/authorities 
POST /v3/users/{userId}/authorities 

2. Update authorities
PUT/PATCH /v3/users/authorities/{authId} 
PUT/PATCH /v3/users/{userId}/authorities/{authId} 

3. Delete authorities
DELETE /v3/users/authorities/{authId} 
DELETE /v3/users/{userId}/authorities/{authId}

你怎么看？直觉上，我在所有情况下都选择第一个选项，但可能不是从 body 传递 userId 的最好方法（我认为从 url 传递它更好）。或者我应该实现两个端点吗？

Answer 1

第二种方法更简洁、更标准。

PUT/PATCH/POST/DELETE.. /v3/users/authorities/{authId} - [1]
PUT/PATCH/POST/DELETE.. /v3/users/{userId}/authorities/{authId} -[2]

在这里，例如，如果您在 uri 中传递 authId，为什么不传递 userId？您将在此处遵循的标准是 "resource/{uniqueId}/attribute/{uniqueId}"。理想情况下，在您的后端代码中，您首先查找特定资源，然后使用 uri 中传递的 keys/ids 查找同一资源的特定属性。当操作将影响所有资源时，将省略 id！

如果您使用方法 [1]，您似乎在尝试 add/update/delete 所有用户的权限！绝对不是这样。

在form/post数据中发送userId是可行的，但不是正确的做法。在您的 form/post 数据中，您应该发送将成为 added/updated 的值（在 PUT/POST 的情况下）。类似于 {authType: 'Admin', isGlobal: true, effectiveFrom: '12/12/2015'}。很明显，这里放不下userId。

Answer 2

首先，让我说我同意 Arghya 给出的答案，但我确实认为可以将这些 UPDATE 和 DELETE url 缩短到 v3/authorities/{authId}。

当然，这假设 authId 对于整个应用程序的授权机构是唯一的。我个人认为指定用户没有意义。到达该路线的人是否可以访问该资源。

请记住 RESTful 只是一种架构风格。您应该做最适合您的技术堆栈并且对您和与之交互的客户最有意义的事情 API。

Restful API 设计：用户端点和权限端点应该如何设计？

Restful API design: how should user's and authority's endpoints be?

api

rest

endpoint

restful-architecture