DELETE 请求正文的 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

大多数讨论似乎都同意在 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:

• 消息体 - 规范表明 DELETE 上的消息体没有语义价值；HTTP 客户端不完全支持；不是标准做法
• 自定义 HTTP 标头 - 需要自定义标头通常是 违反标准做法；使用它们与我的 API 的其余部分不一致，它们都不需要自定义标头；此外，没有好的 HTTP 响应可用于指示错误的自定义标头值(可能完全是一个单独的问题)
• 标准 HTTP 标头 - 没有合适的标准标头
• 查询参数 - 添加查询参数实际上改变了被删除的请求 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 请求正文的 RESTful 替代方案的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！