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

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

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

我的问题:

这完全是个好主意吗?HTTP客户端在GET请求中使用请求体时会遇到问题吗?

https://www.rfc-editor.org/rfc/rfc2616


当前回答

我不建议这样做,这违背了标准做法,也没有提供那么多回报。您希望保留内容的正文,而不是选项。

其他回答

虽然您可以做到这一点,但只要HTTP规范没有明确排除它,我建议避免它,因为人们不希望事情以这种方式工作。HTTP请求链中有许多阶段,虽然它们“大部分”符合HTTP规范,但唯一可以保证的是,它们的行为将与web浏览器传统使用的一样。(我想的是透明代理、加速器、A/V工具包等)

这就是稳健性原则背后的精神。大致上,“接受的内容要自由,发送的内容要保守”,你不想在没有充分理由的情况下突破规范的界限。

然而,如果你有充分的理由,那就去做吧。

如果您真的想将可计算的JSON/XML正文发送到web应用程序,那么放置数据的唯一合理位置是使用RFC4648:Base64Encoding和URL和文件名安全字母表编码的查询字符串。当然,您可以只对JSON进行URL编码,并将其放入URL参数的值中,但Base64给出的结果较小。请记住,URL大小有限制,请参阅不同浏览器中URL的最大长度是多少。

您可能会认为Base64的padding=字符可能对URL的参数值有害,但这似乎不是-请参阅以下讨论:http://mail.python.org/pipermail/python-bugs-list/2007-February/037195.html . 但是,您不应该将编码数据放在没有参数名称的位置,因为带填充的编码字符串将被解释为具有空值的参数键。我会用类似的东西_b64=<编码器数据>。

得到,用身体!?

在规范方面,你可以,但是,这不是一个好主意,我们将看到这样做是不明智的。

RFC 7231§4.3.1规定身体“没有定义的语义”,但这并不是说它是被禁止的。如果你在请求中附加了一个主体,那么你的服务器/应用程序将从中得到什么,这取决于你。RFC继续声明GET可以是“各种数据库记录的编程视图”。显然,这样的视图多次由大量输入参数定制,这些参数放在请求目标的查询组件中并不总是方便甚至安全的。

好的:我喜欢冗长的辞藻。很明显,读取/获取资源不会对服务器产生任何可观察到的副作用(该方法是“安全的”),并且无论第一个请求的结果如何,都可以以相同的预期效果重复请求(该方法“幂等”)。

糟糕的是:HTTP/1.1的早期草案禁止GET具有主体,而且据称,某些实现直到今天都会丢弃主体、忽略主体或拒绝消息。例如,哑HTTP缓存可能只从请求目标构建缓存密钥,而忽略了主体的存在或内容。更愚蠢的服务器可能会如此无知,以至于将主体视为一个新的请求,这实际上被称为“请求走私”(这是将“请求发送到一个设备,而另一个设备不知道它”的行为-源)。

由于我认为主要关注的是实现之间的不可操作性,正在进行的工作建议将GET主体分类为“不应该”,“除非(请求)直接发送给一个源服务器,该服务器先前已在带内或带外表示此类请求有目的,并且将得到充分支持”(我的重点)。

解决方法:对于这种方法的一些问题,可以使用一些技巧。例如,不知道主体的缓存可以通过简单地将从主体派生的哈希附加到查询组件来间接地变得知道主体,或者通过响应缓存控制(没有来自服务器的缓存头)来完全禁用缓存。

唉,当涉及到请求链时,人们往往无法控制——甚至无法意识到所有当前和未来的HTTP中介以及它们将如何处理GET主体。这就是为什么这种方法通常被认为是不可靠的。

但是POST不是幂等的!

POST是一种替代方法。POST请求通常包括一个消息体(仅用于记录,正文不是要求,请参阅RFC 7230§3.3.2)。RFC 7231(§4.3.3)中的第一个用例示例是“向数据处理过程提供数据块[…]”。所以,就像GET与身体一样,身体在后端发生什么取决于你。

好处:当您希望出于任何目的发送请求体时,也许可以采用一种更常见的方法,这样可能会从您的团队成员中产生最少的噪音(有些人可能仍然错误地认为POST必须创建资源)。

此外,我们经常向其传递参数的是一个对不断变化的数据进行操作的搜索函数,只有在响应中提供明确的新鲜度信息时,POST响应才可缓存。

糟糕的是:POST请求没有被定义为幂等,导致请求重试犹豫。例如,在页面重新加载时,浏览器不愿意重新提交HTML表单,而不会向用户提示不可读取的隐藏消息。

解决方法:好吧,POST没有被定义为幂等并不意味着它不一定是幂等的。事实上,RFC 7230§6.3.1写道:“知道(通过设计或配置)对给定资源的POST请求是安全的用户代理可以自动重复该请求”。因此,除非您的客户端是HTML表单,否则这可能不是真正的问题。

QUERY是圣杯

有人提出了一种新的方法QUERY,它确实定义了消息体的语义,并将该方法定义为幂等。看看这个。

编辑:顺便说一句,我在发现了一个代码库后,无意中遇到了这个StackOverflow问题,在该代码库中,他们只将PUT请求用于服务器端搜索功能。这是他们的想法,包括一个带参数的体,并且也是幂等的。遗憾的是,PUT的问题在于请求体具有非常精确的语义。具体来说,PUT“请求创建目标资源的状态或将其替换为[正文]中的状态”(RFC 7231§4.3.4)。显然,这排除了PUT作为一个可行的选项。

IMHO,您只需在URL中发送JSON编码(即encodeURIComponent),这样就不会违反HTTP规范并将JSON发送到服务器。

关于一个老问题的想法:

在正文中添加完整的内容,在查询字符串中添加正文的短哈希,这样缓存就不会有问题(如果正文内容发生变化,哈希值会发生变化),并且您可以在需要时发送大量数据:)