我正在为我们的应用程序开发一个新的RESTful Web服务。
当对某些实体执行GET时，客户端可以请求实体的内容。如果他们想添加一些参数（例如排序列表），可以在查询字符串中添加这些参数。
或者，我希望人们能够在请求主体中指定这些参数。HTTP/1.1似乎并没有明确禁止这一点。这将允许他们指定更多信息，可能会更容易指定复杂的XML请求。
我的问题：
这完全是个好主意吗？HTTP客户端在GET请求中使用请求体时会遇到问题吗？
https://www.rfc-editor.org/rfc/rfc2616
当前回答
如果您真的想将可计算的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=<编码器数据>。
其他回答
虽然您可以做到这一点，但只要HTTP规范没有明确排除它，我建议避免它，因为人们不希望事情以这种方式工作。HTTP请求链中有许多阶段，虽然它们“大部分”符合HTTP规范，但唯一可以保证的是，它们的行为将与web浏览器传统使用的一样。（我想的是透明代理、加速器、A/V工具包等）
这就是稳健性原则背后的精神。大致上，“接受的内容要自由，发送的内容要保守”，你不想在没有充分理由的情况下突破规范的界限。
然而，如果你有充分的理由，那就去做吧。
我向IETF HTTP工作组提出了这个问题。Roy Fielding（1998年，http://1.1文档的作者）的评论是
“…一个实现将被破坏，无法执行除解析和丢弃该主体之外的任何操作”
RFC 7213（HTTPbis）规定：
“GET请求消息中的有效负载没有定义的语义；”
现在看来很明显，其意图是禁止GET请求体上的语义，这意味着请求体不能用于影响结果。
如果你在GET上包含一个主体，那么有一些代理肯定会以各种方式破坏你的请求。
总之，不要这样做。
IMHO，您只需在URL中发送JSON编码（即encodeURIComponent），这样就不会违反HTTP规范并将JSON发送到服务器。
即使一个流行的工具使用了这个，正如本页经常引用的，我认为这仍然是一个非常糟糕的主意，因为它太奇特了，尽管规范没有禁止。
许多中间基础设施可能只是拒绝这样的请求。
例如，忘记在网站前面使用一些可用的CDN，如下图所示：
如果查看器GET请求包含正文，CloudFront将向查看器返回HTTP状态代码403（禁止）。
是的，您的客户端库也可能不支持发出这样的请求，如本文评论中所述。
我不建议这样做，这违背了标准做法，也没有提供那么多回报。您希望保留内容的正文，而不是选项。
