相关疑难解决方法(0)

我正在为我们的应用程序开发一个新的RESTful Web服务.

在某些实体上执行GET时,客户端可以请求实体的内容.如果他们想要添加一些参数(例如排序列表),他们可以在查询字符串中添加这些参数.

或者,我希望人们能够在请求正文中指定这些参数. HTTP/1.1似乎没有明确禁止这一点.这将允许他们指定更多信息,可以更容易指定复杂的XML请求.

我的问题:

• 这完全是一个好主意吗？
• HTTP客户端在GET请求中使用请求主体会有问题吗？

http://tools.ietf.org/html/rfc2616

虽然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请求中包含此类必需的元数据？还有其他我没有考虑的替代方案吗？