有理由的 RESTful DELETE

Question

对于最终将被软删除(isDeleted 标志)删除的资源，我希望提供与资源一起存储以供审计的原因。

我遇到的选项感觉都不对。

1. 自定义 HTTP header
2. 删除正文

我也考虑过使用 PUT，但我要放置的内容与构成典型更新资源的内容不同。

从 RESTful 的角度来看，哪种方法最有意义？

Answer 1

DELETE使用主体是错误的，因为它不尊重 HTTP 规范中定义的统一接口(interface)的语义。

A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause some existing implementations to reject the request.

请注意，此处使用的拼写与 GET 的有效负载相同请求。

从语义上讲，DELETE 是正确的选择；软删除与硬删除“超出了规范的范围”，也就是说它是一种实现选择。

但是传达“原因”会给您带来两个需要解决的问题。一个是把这个原因放在哪里，答案当然是use a header。 .

New header fields can be defined such that, when they are understood by a recipient, they might override or enhance the interpretation of previously defined header fields, define preconditions on request evaluation, or refine the meaning of responses.

可以翻看message-headers registry查看是否与您的要求非常匹配，如果没有，您可以定义自己的要求。

第二个问题是弄清楚如何与客户端通信，以便它知道使用 header 字段。今天最常见的方法是将 header 写入 API 的描述中，但这不是完全 REST。

REST 答案是您的超媒体规范描述了服务器如何与客户端通信哪些 header 很重要，以及应该将哪些数据放在那里。想象一个带有“字段值”输入控件的 HTML 表单，您的想法是正确的。

没有多少 API 愿意这样做。

PUT 是一个有趣的选择；规则中没有任何内容表明资源只能具有一种内容类型，或者端点必须仅接受一种内容类型。

例如，RFC 7807定义 application/problem+json，一种用于报告来自服务器的问题的简单表示。但是，您没有理由不能将应用程序/问题 + json 表示形式放入资源以引发软删除。

此规范为您提供了一个 title 和一个 details 元素供您使用，因此客户有工作空间。

当然也不一定非得是application/problem+json——你可以自己设计一个更合适的media type。

同样，您遇到与使用带有自定义 header 的删除类似的问题:客户端如何发现您的资源支持放置删除？