RESTful API中实体特定更新操作的合规设计方案咨询

首先直接排除你纠结的两个方案：

• POST /carts/:id/:status 和 DELETE /carts/:id/:status：POST语义是创建资源，这里是修改购物车状态，完全不匹配；DELETE是删除资源，更不搭，直接pass。
• PATCH /carts/:id/:status：PATCH要求携带部分更新的字段，空负载不符合这个方法的常规用法，而且把状态放路径里也违背了PATCH操作资源属性的语义，不合适。

最适配现有规则的方案：POST 到状态转换子资源 #

用 POST /carts/:id/status-transitions，请求体携带目标状态：

{
  "target_status": "confirmed"
}

这个方案完全贴合你的API规则：

• 符合POST的语义：这里本质是创建一条状态变更记录资源（哪怕你不需要持久化这条记录，语义上POST就是发起一个创建操作的动作，完全合理）。
• 满足安全要求：后端可以在这个接口里严格校验状态转换的合法路径（比如不允许从refused直接跳到confirmed），只开放你指定的几种状态变更，避免非法操作。
• 结构清晰：和普通的PATCH部分更新（比如修改购物车商品数量）做了明确区分，维护起来更方便。

其他可选方案 #

如果你的状态类型不多，也可以用独立动作接口：

• POST /carts/:id/confirm：确认订单
• POST /carts/:id/partially-confirm：部分确认
• POST /carts/:id/refuse：拒绝订单

每个接口只处理一种状态变更，语义极致明确，安全校验逻辑更简单，但缺点是状态增多时接口数量会跟着涨，适合状态数量少的场景。

另外，如果你不排斥用PATCH但要严格限制操作，也可以用 PATCH /carts/:id，请求体只允许携带status字段，但这不符合你"不通过PATCH实现特定更新操作"的要求，所以优先级低于上面两个方案。

内容的提问来源于stack exchange，提问作者gremo