RESTful API中不可缓存用户调用：DELETE/PUT/PATCH最优方案

核心原则 #

RESTful路由设计要兼顾资源语义清晰度与上下文复用，利用登录session获取的用户身份信息，避免路径中出现冗余的user_id参数。

三种方案分析 #

1. 原方案（不推荐）

DELETE /api/user/{user_id}/friends/{friend_id}

user_id属于冗余参数，既然后端可通过session直接获取当前登录用户ID，路径中重复传递只会增加前端维护成本，毫无必要。

2. 路径带friend_id的方案（优先推荐）

DELETE /api/user/friends/{friend_id}

• 符合RESTful语义：URL清晰表达“当前登录用户的某一好友资源”，直接对应要删除的目标资源。
• 调用逻辑直观：前端调用时直接将friend_id嵌入路径，写法符合HTTP方法的常规用法：

  axios.delete(`/api/user/friends/${friend_id}`)
  

• 后端逻辑简洁：从session取当前用户ID，结合路径中的friend_id执行删除校验与操作，流程清晰。

3. 请求体传friend_id的方案（不推荐）

DELETE /api/user/friends/

前端正确调用写法：

axios.delete(`/api/user/friends/`, { data: { friend_id } })

• 违反HTTP语义：DELETE方法的核心是删除指定资源，资源标识应放在URL路径中，而非请求体。虽然HTTP标准未严格禁止DELETE带请求体，但多数客户端、网关对这种用法的支持存在兼容性问题。
• 可读性差：从URL无法直接判断操作目标，调试与维护成本更高。

扩展到PUT/PATCH场景 #

对于PUT（全量更新）、PATCH（增量更新）请求，同样遵循单资源操作的原则：

• 单资源修改：比如修改好友备注，用PATCH /api/user/friends/{friend_id}，请求体传递更新内容。
• 批量操作例外：如果是批量删除/修改好友，可使用DELETE /api/user/friends或PATCH /api/user/friends，请求体传递批量ID列表，但这属于特殊场景，单资源操作仍优先将标识放在路径中。

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