http - DELETE 请求正文的 RESTful 替代方案

Question

而HTTP 1.1 spec似乎允许 DELETE 上的消息正文请求，它似乎表明服务器应该忽略它，因为它没有定义的语义。

4.3 Message Body

A server SHOULD read and forward a message-body on any request; if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request.

我已经在 SO 及其他平台上回顾了有关此主题的一些相关讨论，例如:

• Is an entity body allowed for an HTTP DELETE request?
• Payloads of HTTP Request Methods
• HTTP GET with request body

大多数讨论似乎都同意在 DELETE 上提供消息正文可能是允许的，但通常不建议这样做。

此外，我注意到各种 HTTP 客户端库中的一种趋势，这些库似乎正在记录越来越多的增强功能，以支持 DELETE 上的请求主体。大多数图书馆似乎都会这样做，尽管最初偶尔会遇到一些阻力。

我的用例要求在删除时添加一些必需的元数据(例如删除的“原因”，以及删除所需的一些其他元数据)。我考虑了以下选项，但没有一个看起来完全合适且符合 HTTP 规范和/或 REST 最佳实践:

• 消息正文 - 规范表明 DELETE 上的消息正文没有语义值； HTTP 客户端不完全支持；不是标准做法
• 自定义 HTTP header - 需要自定义 header 通常是 against standard practices ;使用它们与我的 API 的其余部分不一致，其中都不需要自定义 header ；此外，没有好的 HTTP 响应可用于指示错误的自定义 header 值(可能完全是一个单独的问题)
• 标准 HTTP header - 没有合适的标准 header
• 查询参数 - 添加查询参数实际上会更改要删除的请求 URI； against standard practices
• POST 方法 -(例如 POST/resourceToDelete { deletemetadata })POST 不是用于删除的语义选项； POST 实际上代表了所需的相反操作(即 POST 创建资源从属；但我需要删除该资源)
• 多种方法 - 将 DELETE 请求拆分为两个操作(例如，PUT 删除元数据，然后 DELETE)会将一个原子操作拆分为两个，可能会留下不一致的状态。删除原因(以及其他相关元数据)不是资源表示本身的一部分。

我的第一选择可能是使用消息正文，其次是自定义 HTTP header ；然而，正如所指出的，这些方法也有一些缺点。

是否有任何符合 REST/HTTP 标准的建议或最佳实践，可以在 DELETE 请求中包含此类必需的元数据？还有其他我没有考虑过的替代方案吗？

Answer 1

尽管有些建议不要将消息正文用于 DELETE 请求，但这种方法在某些用例中可能是合适的。这是我们在评估问题/答案中提到的其他选项并与服务的消费者合作后最终使用的方法。

虽然消息正文的使用并不理想，但其他选项也不是完全合适。请求正文 DELETE 使我们能够轻松、清晰地添加 DELETE 操作所需的附加数据/元数据的语义。

我仍然愿意接受其他想法和讨论，但想结束这个问题的循环。我感谢大家对此主题的想法和讨论!