会员注销API命名与RESTful HTTP方法选型技术问询

一、API命名：deregistration vs signout #

• signout的问题：这个术语在行业内几乎和logout同义，特指终止当前登录会话，和“账号注销”（永久取消注册）的语义偏差极大，很容易让开发者误解为退出登录，完全不适合用来命名账号注销API。
• deregistration的优势：这个词明确指向“取消注册”，直接对应账号层面的永久注销操作，语义清晰无歧义。如果追求简洁，也可以用delete配合HTTP方法，但deregistration能更直观地表达API的功能。
  建议优先使用deregistration作为API路径的一部分，比如/users/{userId}/deregistration。

二、HTTP方法选择：当逻辑仅修改状态为pending时 #

• 绝对不能用DELETE：DELETE的RESTful语义是彻底移除目标资源，调用后该URI对应的用户资源应该无法再被访问。如果只是把用户状态改为pending（资源仍然存在，只是状态变更），使用DELETE会完全违背HTTP方法的语义约定。
• 推荐用PATCH：PATCH的语义是对资源进行部分更新，正好匹配“仅修改用户状态为待注销”的逻辑。请求体示例：

{
  "status": "pending"
}

三、符合RESTful规范的会员注销API设计 #

分两种场景适配：

1. 永久删除账号资源：直接对用户资源使用DELETE方法，路径为/users/{userId}，调用后该用户的所有数据被移除，资源不再存在。
2. 触发注销流程（仅标记状态）：优先使用PATCH方法修改用户状态为pending；如果需要记录注销请求的额外信息（比如注销原因），也可以用POST请求到子资源/users/{userId}/deregistration-request，但PATCH更贴合RESTful对资源状态变更的设计原则。

内容的提问来源于stack exchange，提问作者정재연