我正在为我们的应用程序开发一个新的RESTful Web服务。
当对某些实体执行GET时，客户端可以请求实体的内容。如果他们想添加一些参数（例如排序列表），可以在查询字符串中添加这些参数。
或者，我希望人们能够在请求主体中指定这些参数。HTTP/1.1似乎并没有明确禁止这一点。这将允许他们指定更多信息，可能会更容易指定复杂的XML请求。
我的问题：
这完全是个好主意吗？HTTP客户端在GET请求中使用请求体时会遇到问题吗？
https://www.rfc-editor.org/rfc/rfc2616
当前回答
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=<编码器数据>。
根据RFC 2616第4.3节“消息正文”：
服务器应读取并转发任何请求的消息体；如果请求方法不包括实体实体的定义语义，则在处理请求时应忽略消息体。
也就是说，服务器应该始终从网络中读取任何提供的请求体（检查内容长度或读取分块体等）。此外，代理应该转发他们收到的任何此类请求。然后，如果RFC为给定方法的主体定义了语义，那么服务器实际上可以使用请求主体来生成响应。然而，如果RFC没有定义主体的语义，那么服务器应该忽略它。
这与上面Fielding的引用一致。
第9.3节“GET”描述了GET方法的语义，没有提到请求体。因此，服务器应该忽略它在GET请求中收到的任何请求体。
你可以用身体发送GET，也可以发送POST，然后放弃RESTish宗教信仰（这并不是很糟糕，5年前只有一个信仰的成员——他在上面的评论）。
这两个都不是很好的决定，但发送GET主体可能会防止某些客户端和某些服务器出现问题。
进行POST可能会遇到一些RESTish框架的障碍。
Julian Reschke在上文中建议使用非标准HTTP头，如“SEARCH”，这可能是一个很好的解决方案，只是它不太可能被支持。
列出能够和不能做到上述每一项的客户可能是最有成效的。
无法发送带有正文的GET的客户端（我知道）：
XmlHTTPRequest Fiddler
可以发送带有正文的GET的客户端：
大多数浏览器
可以从GET检索正文的服务器和库：
阿帕奇PHP文件
从GET中剥离主体的服务器（和代理）：
?
如果您希望允许带有主体的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替换它们（调试总是很有趣！）。
我不建议这样做，这违背了标准做法，也没有提供那么多回报。您希望保留内容的正文，而不是选项。
