分配/取消分配数据的端点命名约定答案

【问题标题】：Endpoint naming convention for assigning/unassigning data分配/取消分配数据的端点命名约定
【发布时间】：2020-08-20 02:42:30
【问题描述】：

想象一下，例如绑定表 user_tasks(user_id, task_id) 与 m:n 关系。我想插入新记录。如果记录已插入或此类记录已存在，端点应返回 204 Status No Content。你会如何组成这样的端点？
- GET users/{user_id}/tasks/{task_id}
- POST users/{user_id}/tasks/{task_id}
- PUT users/{user_id}/tasks/{task_id}
- PUT user_tasks + payload: {"user_id": 1, "task_id": 2}
- 还有别的吗？

我个人会使用 GET，因为方法是幂等的（如果我理解正确的话）并且它不包含有效负载，但我不确定。

现在假设该表还有一个列：user_tasks(user_id, task_id, position)。这里最好的解决方案是什么？
- GET users/{user_id}/tasks/{task_id}/position/{position}
- POST user_tasks + payload: {"user_id": 1, "task_id": 2, "position": 3}
- POST users/{user_id}/tasks/{task_id} + payload: {"position": 3}
- PUT users/{user_id}/tasks/{task_id} + payload: {"position": 3}
- 还有别的吗？

我们的项目中有这两种情况。

【问题讨论】：

客户端是否可以决定任务 ID？

标签： rest http naming-conventions http-method

【解决方案1】：

看起来PUT 比GET 更适合您的任务，因为GET 不应修改服务器上的状态。
来自RFC 2616：

GET 方法意味着检索由 Request-URI 标识的任何信息（以实体的形式）

也从那里：

安全方法：特别是，已经建立了约定，即 GET 和 HEAD 方法不应具有采取除检索之外的操作的意义。这些方法应该被认为是“安全的”

另一方面，对于 PUT：

PUT 方法请求将封闭的实体存储在提供的 Request-URI 下。如果 Request-URI 引用一个已经存在的资源，封闭的实体应该被认为是源服务器上的一个修改版本。

似乎很合适，因为提到了某些资源已经存在的可能性，我们可能不想再次创建它。 PUT 也被认为是幂等的。

现在假设该表将有另一列：user_tasks(user_id, task_id, position)。这里最好的解决方案是什么？

最佳解决方案是选择最适合您和 API 用户的方法。这里唯一可能的缺点可能是提到的两个方案之一与 API 中的其他方案不相似，一些用户可能会发现它出乎意料。

我个人会使用PUT users/{user_id}/tasks/{task_id}/assign?position=3 或使用您的方法，其中参数通过有效负载传递。我认为 URI 应该是一些可识别的资源，而 user_tasks 看起来不像一个。它看起来像一个动作名称，通常可以在 URI 的末尾看到，例如，看howTwitter 就是这样做的。

【讨论】：