Javascript 在GET请求中使用body

我正在为我的一个项目开发RESTAPI。 我需要使用GET请求。我似乎不明白为什么使用url查询字符串优于正文

这两种请求数据的方式之间有一些明显的区别，比如能够看到url中的参数，或者请求可以保存在浏览器的历史记录中

但还有别的吗？

---

使用body请求数据不好吗？

使用body没有什么错

GET

方法没有主体，这不是因为对主体的使用存在偏见

如果您了解HTTP协议规范，您可能会有一些见解：

“GET方法意味着检索任何信息（以 实体）由请求URI标识。“

更简单地说，

GET

方法被创建为仅使用URI检索某些资源。更简单的说，如果您可以仅使用URI获取某些资源-

get

是您应该使用的方法

事实上，您可以发送带有

GET

请求的正文，但它将被忽略（更多信息如下：）

如果出于任何原因需要传递实体，则需要使用不同的方法<代码>发布是一个突出的例子：

“POST方法用于请求源服务器接受 作为资源的新下属包含在请求中的实体 由请求行中的请求URI标识。“

如果您使用RESTAPI，我强烈建议您阅读HTTP规范

用body请求数据是否不好

是的，很糟糕

问题是，在HTTP中，GET被专门定义为不包含请求体

GET请求消息中的有效负载没有定义的语义；在GET请求上发送有效负载正文可能会导致某些现有实现拒绝该请求。-

这里的情况主要是，HTTP规范的早期版本在处理请求中的消息体方面存在一些模糊性。实际上，将消息体放入GET请求是“未定义的行为”

工作组强烈希望确保该标准保持向后兼容

休息点的一部分是我们都在使用一个共同的标准，因此通用工具（浏览器、缓存、反向代理、爬行器等）适用于所有人——或者更具体地说，适用于遵守该标准的所有人

关于<代码>获取< /代码>，包括一个消息体在考虑缓存语义时是没有意义的。HTTP中的缓存语义目前由定义，高层总结是目标uri是主缓存密钥；缓存只需要理解HTTP请求中的元数据就可以正常工作

如果我们要将语义应用于GET请求的主体，我们还需要以一般方式定义这些语义如何影响缓存行为

例如，如果设想一个查询场景（如GraphQL），响应中的预期表示取决于编码到请求体中的信息。因此，现在您需要开始定义两个请求主体何时“相同”——空白是否重要？内容编码重要吗？如果身体有拉链呢？等等

我们对请求（例如POST）没有这种问题，因为符合标准的缓存必须通过不安全的请求进行写入。不需要研究请求消息体的表示，因为在任何情况下，内容都不会改变此要求

有人试图为HTTP方法创建一个新的安全标准，并包含一个消息体。这可能是可行的；在这个意义上，我们引入了一个新的方法令牌，并声明语义是安全的（这样我们就可以在不可靠的网络上执行抢占式抓取和重复请求），也许公共缓存不能存储响应，但必须将每个请求转发给源服务器

这就是说，人们已经意识到这一差距有一段时间了，而且这个问题还没有一个标准化的解决方案——因此可能有一些不明显的困难方面（除了收养与惰性的政治问题）