相关疑难解决方法(0)

虽然HTTP 1.1规范似乎允许DELETE请求上的消息体,但它似乎表明服务器应该忽略它,因为它没有定义的语义.

4.3消息正文

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

我已经回顾了有关SO及其他内容的几个相关讨论,例如:

• 实体主体是否允许HTTP DELETE请求？
• HTTP请求方法的有效负载
• 带请求正文的HTTP GET

大多数讨论似乎都同意允许在DELETE上提供消息体,但通常不建议这样做.

此外,我注意到各种HTTP客户端库中的趋势,这些库中似乎记录了越来越多的增强功能,以支持DELETE上的请求主体.大多数图书馆似乎都有责任,尽管偶尔会有一些初步阻力.

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

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

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

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

HTTP上的Wikipedia条目列出了以下HTTP请求方法:

• HEAD:要求响应与对应于GET请求的响应相同,但没有响应主体.
• GET:请求指定资源的表示.
• POST:将要处理的数据(例如,从HTML表单)提交到标识的资源.数据包含在请求正文中.
• PUT:上传指定资源的表示.
• DELETE:删除指定的资源.
• TRACE:回显收到的请求,以便客户端可以查看中间服务器所做的更改或添加(如果有).
• 选项:返回服务器支持指定URL的HTTP方法.这可以通过请求'*'而不是特定资源来检查Web服务器的功能.
• CONNECT:将请求连接转换为透明的TCP/IP隧道,通常是为了通过未加密的HTTP代理实现SSL加密通信(HTTPS).
• 补丁:用于对资源应用部分修改.

我有兴趣了解(特别是关于前五种方法):

• 哪些方法能够(应该？)接收有效载荷
  • 可以接收有效载荷的方法,它们如何接收？
    • 通过URL中的查询字符串？
    • 通过URL编码的身体？
    • 通过raw/chunked body？
    • 通过上述([全部/部分])的组合？

我很欣赏所有的输入,如果你能分享一些(最好是轻的)阅读,那也很棒!