对于将被删除的资源，最终使用软删除（isDeleted标志），我希望提供一个与资源一起存储的理由，以便进行审计。
我遇到的选项感觉不正确。
我还考虑过使用PUT，但我要放的内容与典型更新中的资源不同。
从RESTful角度来看哪种方法最有意义？
答案 0 :(得分：1)
DELETE是错误的，因为它不尊重HTTP规范中定义的统一接口的语义。
DELETE请求消息中的有效负载没有定义的语义;在DELETE请求上发送有效负载主体可能会导致某些现有实现拒绝该请求。
请注意，此处使用的拼写与GET请求的有效内容相同。
从语义上讲，DELETE是正确的选择; soft vs hard delete超出了规范范围＆＃34;，也就是说它是一种实现选择。
但是传达＆＃34;原因＆＃34;给你解决两个问题。一个是把理由放在哪里，答案当然是use a header。
可以定义新的标题字段，以便当收件人理解它们时，它们可以覆盖或增强对先前定义的标题字段的解释，定义请求评估的前提条件或优化响应的含义。
您可以查看message-headers registry以查看您的要求是否与您的要求非常接近，但如果您未能定义自己的要求，则无法完成。
第二个问题是弄清楚如何与客户端通信，以便它知道使用头字段。今天最常见的方法是将标题写入API的描述中，但这不是完全 REST。
REST的答案是，您的超媒体规范描述了服务器如何与客户端通信哪些标头很重要，以及应该将哪些数据放在那里。想象一下带有＆＃34;字段值＆＃34;的HTML表单。输入控制，你已经有了正确的想法。
没有多少API麻烦这样做。
PUT是一个有趣的选择;规则中没有任何内容表明资源只能有一种内容类型，或者端点必须只接受一种内容类型。
例如，RFC 7807定义了application / problem + json，这是一种从服务器报告问题的简单表示。但是没有理由不能将应用程序/问题+ json表示放到资源上以引发软删除。
此规范为您提供了title和details元素，因此客户可以使用。
当然，它不一定是应用程序/问题+ json - 您可以为自己的设计指定更合适的媒体类型。
同样，您对使用自定义标头的删除存在类似问题：客户端如何发现您的资源支持删除了什么？