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

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

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

我的问题:

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

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


当前回答

关于一个老问题的想法:

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

其他回答

如果您希望允许带有主体的GET请求,一种方法是支持带有标题“X-HTTP-Method-Override:GET”的POST请求。此处描述如下:https://en.wikipedia.org/wiki/List_of_HTTP_header_fields.这个头意味着当方法是POST时,应该将请求视为GET。POST允许Body,因此您可以确定没有人会丢弃GET请求的有效负载。

此标头通常用于通过一些不识别这些方法的代理生成PATCH或HEAD请求,并用GET替换它们(调试总是很有趣!)。

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

例如,它适用于Curl、Apache和PHP。

PHP文件:

<?php
echo $_SERVER['REQUEST_METHOD'] . PHP_EOL;
echo file_get_contents('php://input') . PHP_EOL;

Console命令:

$ curl -X GET -H "Content-Type: application/json" -d '{"the": "body"}' 'http://localhost/test/get.php'

输出:

GET
{"the": "body"}

restclient和REST控制台都不支持这一点,但curl支持。

HTTP规范在第4.3节中说明

如果请求方法规范(第5.1.1节)不允许在请求中发送实体体,则请求中不得包含消息体。

第5.1.1节将我们重定向到第9.x节以了解各种方法。它们都没有明确禁止包含消息体。然而

第5.2节规定

通过检查请求URI和主机头字段来确定由Internet请求标识的确切资源。

第9.3节规定

GET方法意味着检索请求URI标识的任何信息(以实体的形式)。

这一起表明,在处理GET请求时,服务器不需要检查除请求URI和主机头字段之外的任何内容。

总之,HTTP规范不会阻止您使用GET发送消息体,但存在足够的歧义,如果不是所有服务器都支持它,我不会感到惊讶。

如果您真的想将可计算的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=<编码器数据>。