GET HTTP请求有效负载
我正在设计一个API，我想知道在GET请求上发送JSON有效负载是否合适？
在这个其他问题的HTTP请求方法的有效载荷 ，我们可以根据这个链接找到：
- 头部 – 没有定义的身体语义。
- GET – 没有定义的正文语义。
- PUT – 身体支持。
- POST – 支持身体。
- DELETE – 没有定义的正文语义。
- TRACE – 身体不受支持。
- 选项 – 支持身体但没有语义（可能在将来）。
这是否意味着我不应该发送带有效负载的GET请求？ 这样做有风险吗？
- 就像让一些HTTP客户端库无法发送这样的有效载荷一样？
- 或者我的Java API代码无法在某些应用程序服务器上移植？
- 还要别的吗？
我发现ElasticSearch在GET请求上使用了这样的有效负载：
$ curl -XGET 'http://localhost:9200/twitter/tweet/_search?routing=kimchy' -d '{ "query": { "filtered" : { "query" : { "query_string" : { "query" : "some query string here" } }, "filter" : { "term" : { "user" : "kimchy" } } } } } ' 因此，如果这个受欢迎的图书馆做到了并且没有人抱怨，那么也许我可以做同样的事情？
顺便说一句， 我想知道混合queryString参数和JSON有效负载是否可行？ 就像这个ElasticSearch查询一样。 如果是这样，是否有规则，以便我们知道哪些参数应该是queryString参数或有效负载参数？
在这里我们可以阅读： HTTP GET与请求正文
罗伊菲尔丁关于将一个机构纳入GET请求的评论。
是。 换句话说，任何HTTP请求消息都允许包含消息体，因此必须解析消息。 但是，GET的服务器语义受到限制，使得正文（如果有的话）对请求没有语义含义。 解析的要求与方法语义的要求是分开的。
所以，是的，您可以使用GET发送一个正文，不，这样做永远不会有用。
这是HTTP / 1.1的分层设计的一部分，一旦规范被分区（正在进行中），它将再次变得清晰。
罗伊….
然后我真的不明白为什么它永远不会有用，因为在我看来，将复杂的查询发送到服务器是不合适的，这些查询不适合queryParam或matrixParam。 我认为ElasticSearch API设计师也这么认为……
我打算设计一个可以这样调用的API：
curl -XGET 'http://localhost:9000/documents/inbox?pageIndex=0&pageSize=10&sort=title' curl -XGET 'http://localhost:9000/documents/trash?pageIndex=0&pageSize=10&sort=title' curl -XGET 'http://localhost:9000/documents/search?pageIndex=0&pageSize=10&sort=title' -d '{ "someSearchFilter1":"filterValue1", "someSearchFilter2":"filterValue2", "someSearchFilterList": ["filterValue3","xxx"] ... a lot more ... } '
你觉得好吗？ 基于以上考虑。
根据请求正文的GET响应不同会破坏缓存。 不要去那里。
Google App Engine是一种流行的Web框架，它使用特殊的url fetch库，它不支持使用有效负载发出HTTP GET请求 。 因此，如果您希望自己的API能够覆盖Google App Engine用户，那么我不建议您要求此行为。
我已经用谷歌打开了这个问题 。
另请参阅： 带请求正文的HTTP GET – 有关详细信息。
要点是：是的，你可以，但你可能不应该出于各种原因，包括：
- 您可能忽略了HTTP规范建议（您可能想要POST）
- 您可以介绍缓存问题
- 就REST API而言，这并不直观
仅仅因为你可以做某事，并不意味着你应该做 。 我很抱歉，如果这听起来令人愤怒的重复，但关于标准的事情是它们是标准的 – 而HTTP是最成熟的标准之一。 它并不完美，很多人都希望改变它的很多东西，但几乎每个人仍在使用URL参数这样的事实对我来说是充分的迹象表明没有任何可靠的替代品现在。
来自speedplane和Julian Reschke的答案提供了两个具体的例子，如果您依赖于具有正文/有效负载的GET请求，这些事情将会中断。 如果您愿意，您可以将您的应用程序编写为与其他人不同的方式，但网络是标准应该比正常情况更严重的标准。 我知道成为开拓者很有吸引力，但是要充分尊重，请考虑存在多少个网站，以及有多少网络程序员在构建和维护它们。 如果有一个明确更好的方法，你很可能会看到它现在广泛用于生产。
标准的变化/被慢慢采用，因为很多人必须同意这些标准才能让他们工作。 你说有些应用程序违反规则是正确的，但是你会注意到它们已经给人们带来了麻烦，并且在某些情况下需要采用变通方法/冗余措施，正如Aetherus在对另一个答案的评论中提到的那样。 在这样的问题上，我倾向于采取阻力最小的道路。 如果你真的想这样做，我相信你可以让它成功。