REST架构下资源软删除的HTTP请求方法选择探讨

在REST架构里，软删除的实现没有绝对统一的标准答案，但行业里主要有两种主流方案，各有适用场景：

方案一：使用DELETE方法，后台执行标记逻辑 #

这种方式就是像Stripe那样，对外暴露DELETE接口，用户调用后后台不做硬删除，而是给资源打上类似is_active=0或deleted_at的标记，同时返回符合预期的响应（比如200 OK或204 No Content）。并且保留已标记资源的检索能力，用于历史追踪或合规需求。

Stripe的官方说明（翻译后）：

与其他对象不同，已删除的客户仍可通过API检索，以便在移除信用卡信息、阻止后续操作（如添加新订阅）的同时，追踪客户历史记录。

这种方案的核心优势是贴合用户直觉——用户认知里的"删除"动作对应REST的DELETE方法，接口语义和用户操作预期匹配；同时软删的逻辑对客户端完全透明，不需要客户端额外理解状态变更的细节。

方案二：使用PUT/PATCH方法修改资源状态 #

把软删除看作是资源状态的一次更新，通过PATCH /resource/{id}（或PUT）发送请求，在请求体中明确设置资源的状态字段，比如{ "is_active": false }或{ "status": "deleted" }。

这种方案的优势是严格遵循REST语义，明确告知客户端这是对资源属性的修改，而非真正移除资源。适合需要让客户端清晰感知到"只是标记为删除，资源并未消失"的场景，或者需要在标记删除的同时修改其他关联属性的情况。

选择建议 #

• 如果希望接口简洁直观，让用户觉得就是在"删除"资源，且后台软删逻辑无需客户端感知，优先选DELETE方案（参考Stripe的实践）
• 如果需要明确传递"状态变更"的语义，或者业务上需要客户端知晓软删的本质，优先选PUT/PATCH方案

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