DELETE Request Body的RESTful替代方案 [英] RESTful Alternatives to DELETE Request Body

问题描述

HTTP 1.1规范似乎允许 DELETE 请求中的邮件正文，似乎表明服务器应忽略它，因为它没有定义的语义。

While the HTTP 1.1 spec seems to allow message bodies on DELETE requests, it seems to indicate that servers should ignore it since there are no defined semantics for it.

4.3消息正文

服务器应该在任何请求中读取和转发消息体;如果
请求方法不包含实体主体的定义语义，
那么在处理请求时应该忽略消息体。

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和更多内容上回顾了关于此主题的几个相关讨论，例如：

I've already reviewed several related discussions on this topic on SO and beyond, such as:

• 是否允许实体正文发出HTTP DELETE请求？


• HTTP请求方法的有效负载


• 带请求正文的HTTP GET

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

大多数讨论似乎都认为在DELETE上提供邮件正文可能允许，但通常不会建议。

Most discussions seem to concur that providing a message body on a DELETE may be allowed, but is generally not recommended.

此外，我注意到各种HTTP客户端库中的趋势似乎正在记录这些库以支持DELETE上的请求主体的更多增强功能。大多数库似乎都有必要，虽然偶尔会有一些初始阻力。

Further, I've noticed a trend in various HTTP client libraries where more and more enhancements seem to be getting logged for these libraries to support request bodies on DELETE. Most libraries seem to oblige, although occasionally with a little bit of initial resistance.

我的用例要求在DELETE上添加一些必需的元数据（例如原因 删除，以及删除所需的其他元数据。我已经考虑了以下选项，其中任何一个看起来都不合适，并且与HTTP规范和/或REST最佳实践内联：

My use case calls for the addition of some required metadata on a DELETE (e.g. the "reason" for deletion, along with some other metadata required for deletion). I've considered the following options, none of which seem completely appropriate and inline with HTTP specs and/or REST best practices:

• Message Body - 规范表明DELETE上的消息体没有语义值; HTTP客户端不完全支持;非标准做法


• 自定义HTTP标头 - 要求自定义标头通常违反标准做法;使用它们与我的其余API不一致，其中没有一个需要自定义标头;此外，没有良好的HTTP响应可用于指示错误的自定义标头值（可能是一个单独的问题）


• 标准HTTP标头 - 没有标准标头是合适的


• 查询参数 - 添加查询参数实际上会更改要删除的Request-URI; 违反标准做法


• POST方法 - （例如 POST / resourceToDelete {deletemetadata} ）POST不是用于删除的语义选项; POST实际上代表了所需的相反操作（即POST创建资源下属;但我需要删除资源）


• 多种方法 - 将DELETE请求拆分为两个操作（例如，PUT删除元数据，然后删除DELETE）将原子操作拆分为两个，可能会留下不一致的状态。删除原因（和其他相关元数据）不是资源表示本身的一部分。

• Message Body - The spec indicates that message bodies on DELETE have no semantic value; not fully supported by HTTP clients; not standard practice
• Custom HTTP Headers - Requiring custom headers is generally against standard practices; using them is inconsistent with the rest of my API, none of which require custom headers; further, no good HTTP response available to indicate bad custom header values (probably a separate question altogether)
• Standard HTTP Headers - No standard headers are appropriate
• Query Parameters - Adding query params actually changes the Request-URI being deleted; against standard practices
• POST Method - (e.g. POST /resourceToDelete { deletemetadata }) POST is not a semantic option for deleting; POST actually represents the opposite action desired (i.e. POST creates resource subordinates; but I need to delete the resource)
• Multiple Methods - Splitting the DELETE request into two operations (e.g. PUT delete metadata, then DELETE) splits an atomic operation into two, potentially leaving an inconsistent state. The delete reason (and other related metadata) are not part of the resource representation itself.

我的第一个偏好可能是使用消息体，第二个自定义HTTP标头;但是，如上所述，这些方法存在一些缺点。

My first preference would probably be to use the message body, second to custom HTTP headers; however, as indicated, there are some downsides to these approaches.

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

Are there any recommendations or best practices inline with REST/HTTP standards for including such required metadata on DELETE requests? Are there any other alternatives that I haven't considered?

推荐答案

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

Despite some recommendations not to use the message body for DELETE requests, this approach may be appropriate in certain use cases. This is the approach we ended up using after evaluating the other options mentioned in the question/answers, and after collaborating with consumers of the service.

使用消息时身体并不理想，其他选择也都不合适。请求体DELETE允许我们轻松清楚地添加伴随DELETE操作所需的其他数据/元数据的语义。

While the use of the message body is not ideal, none of the other options were perfectly fitting either. The request body DELETE allowed us to easily and clearly add semantics around additional data/metadata that was needed to accompany the DELETE operation.

我仍然对其他想法持开放态度和讨论，但想关闭这个问题的循环。我感谢大家对这个主题的想法和讨论！

I'd still be open to other thoughts and discussions, but wanted to close the loop on this question. I appreciate everyone's thoughts and discussions on this topic!

这篇关于DELETE Request Body的RESTful替代方案的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！