java GET HTTP 请求负载

GET HTTP request payload

提问by Sebastien Lorber

I am designing an API and I wonder if it is fine to send a JSON payload on a GET request?

我正在设计一个 API，我想知道是否可以在 GET 请求上发送 JSON 有效负载？

In this other question Payloads of HTTP Request Methods, we can find according to this link:

在另一个问题Payloads of HTTP Request Methods 中，我们可以根据此链接找到：

• HEAD - No defined body semantics.
• GET - No defined body semantics.
• PUT - Body supported.
• POST - Body supported.
• DELETE - No defined body semantics.
• TRACE - Body not supported.
• OPTIONS - Body supported but no semantics (maybe in the future).

• HEAD - 没有定义的正文语义。
• GET - 没有定义的正文语义。
• PUT - 支持身体。
• POST - 支持正文。
• DELETE - 没有定义的正文语义。
• TRACE - 不支持正文。
• 选项 - 支持正文但没有语义（可能在未来）。

Does this mean that I should not send a GET request with a payload?Are there risks to do so?

这是否意味着我不应该发送带有有效负载的 GET 请求？这样做有风险吗？

• Like having some HTTP client libraries incapable of sending such a payload?
• Or my Java API code not being portable on certain application servers?
• Anything else?

• 就像某些 HTTP 客户端库无法发送这样的有效负载一样？
• 或者我的 Java API 代码不能在某些应用服务器上移植？
• 还要别的吗？

---

---

I found out that ElasticSearch was using such a payload on a GET request:

我发现 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" }
            }
        }
    }
}
'

So if this popular libary does it and nobody complains, then perhaps I can do the same?

因此，如果这个流行的图书馆做到了并且没有人抱怨，那么也许我也可以这样做？

By the way, I would like to know if this is OK to mix queryString parameters and JSON payload?Exactly like this ElasticSearch query does. If so, are there rules so that we know which arguments should be queryString parameters, or payload parameters?

顺便说一句，我想知道混合 queryString 参数和 JSON 负载是否可以？就像这个 ElasticSearch 查询一样。如果是这样，是否有规则可以让我们知道哪些参数应该是 queryString 参数或有效载荷参数？

---

---

Here we can read: HTTP GET with request body

在这里我们可以阅读： HTTP GET with request body

Roy Fielding's comment about including a body with a GET request.

Yes. In other words, any HTTP request message is allowed to contain a message body, and thus must parse messages with that in mind. Server semantics for GET, however, are restricted such that a body, if any, has no semantic meaning to the request. The requirements on parsing are separate from the requirements on method semantics.

So, yes, you can send a body with GET, and no, it is never useful to do so.

This is part of the layered design of HTTP/1.1 that will become clear again once the spec is partitioned (work in progress).

....Roy

Roy Fielding 关于在 GET 请求中包含主体的评论。

是的。换句话说，任何 HTTP 请求消息都允许包含消息主体，因此必须考虑到这一点来解析消息。但是，GET 的服务器语义受到限制，因此主体（如果有）对请求没有语义意义。解析的要求与方法语义的要求是分开的。

所以，是的，您可以使用 GET 发送正文，不，这样做永远没有用。

这是 HTTP/1.1 分层设计的一部分，一旦规范被分区（工作正在进行中），它​​将再次变得清晰。

....罗伊

Then I don't really understand why it is never useful, because it makes sense in my opinion to send complex queries to the server that wouldn't fit well on queryParam or matrixParam. I think ElasticSearch API designers think the same...

然后我真的不明白为什么它从来没有用，因为在我看来，将复杂的查询发送到不适合 queryParam 或 matrixParam 的服务器是有意义的。我认为 ElasticSearch API 设计者也这么认为……

---

---

I am planning to design an API which can be called like that:

我打算设计一个可以这样调用的 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 ...
}
'

Does it seem fine to you?Based on the above considerations.

你觉得还好吗？基于以上考虑。

---

---

回答by Julian Reschke

Having the GET response vary based on the request body will break caching. Don't go there.

让 GET 响应因请求正文而异会破坏缓存。不要去那里。

回答by speedplane

Google App Engine, a popular web framework, uses a special url fetch library, which does not support making HTTP GET requests with a payload. Accordingly, if you want your API to reach Google App Engine users, then I would not recommend requiring this behavior.

Google App Engine 是一种流行的网络框架，它使用特殊的 url 提取库，该库不支持使用有效负载发出 HTTP GET 请求。因此，如果您希望您的 API 能够覆盖 Google App Engine 用户，那么我不建议要求这种行为。

I've opened an issue regarding thiswith google.

我已经用谷歌打开了一个关于这个的问题。

回答by a darren

Also see: HTTP GET with request body- for more detail on this.

另请参阅：带有请求正文的 HTTP GET- 有关此内容的更多详细信息。

The gist is: Yes you can, but you probably shouldn't for various reasons, including:

要点是：是的，您可以，但出于各种原因，您可能不应该这样做，包括：

• You're likely ignoring HTTP spec recommendations (you probably want to POST)
• You may introduce caching issues
• This is notintuitive as far as REST APIs go

• 您可能会忽略 HTTP 规范建议（您可能想要 POST）
• 您可能会引入缓存问题
• 就 REST API 而言，这并不直观

回答by Toadfish

Just because you cando something, doesn't mean you should. I'm sorry if this sounds infuriatingly tautological but the thing about standards is that they're standard- and HTTP is one of the most established standards there is. It's not perfect, and there are a lot of things which a lot of people would like to change about it, but the fact that nearly everyone is still using URL parameters for use cases such as this is to me sufficient indication that there aren't any reliable alternatives right now.

仅仅因为您可以做某事，并不意味着您应该这样做。如果这听起来令人恼火，我很抱歉，但关于标准的事情是它们是标准的- HTTP 是最成熟的标准之一。它并不完美，很多人想要改变它的很多东西，但几乎每个人仍在使用 URL 参数来处理这样的用例这一事实对我来说充分表明没有现在有任何可靠的替代品。

The answers from speedplane and Julian Reschke give two concrete examples of things that will break if you rely on GET requests with a body/payload. You can write your app differently to everyone else, if you want, but the web is one area where standards should perhaps be taken even more seriously than normal. I know it's tempting to be a trailblazer, but with all due respect, consider just how many websites exist, and how many web programmers there are building and maintaining them. If there was a definitively better way, you'd most likely see it widely used in production by now.

来自 speedplane 和 Julian Reschke 的答案给出了两个具体的例子，说明如果您依赖带有正文/有效负载的 GET 请求，这些事情将会中断。如果你愿意，你可以用不同的方式编写你的应用程序，但网络是一个领域，标准也许应该比平常更认真。我知道成为开拓者很诱人，但恕我直言，请考虑一下目前有多少网站，以及有多少 Web 程序员在构建和维护这些网站。如果有绝对更好的方法，您现在很可能会看到它在生产中得到广泛使用。

Standards change/are adopted slowly because so many people have to agree on them for them to work. You're correct in saying that there areapplications that break the rules, but you'll notice they've caused headaches for people, and workarounds/redundancy measures are required in certain cases, as mentioned by Aetherus in their comment on another answer. I tend to take the path of least resistance on issues like this. If you really want to do it, I'm sure you can make it work, though.

标准变化/采用缓慢，因为很多人必须同意它们才能工作。你是说，有正确的是不遵守规则的应用程序，但你会发现他们已经头疼不已的人，并须在某些情况下的解决方法/冗余措施，如通过Aetherus在其上的另一个答案评论中提及。在这样的问题上，我倾向于走阻力最小的道路。不过，如果你真的想这样做，我相信你可以让它发挥作用。