为什么HTTP GET参数应该是url的一部分

Question

GET和POST应该是两个不同的动词，它们的目的是不同的。然而，它们带有实施包袱，导致很多混乱。即使只是因为参数显示在网址中，通常也会有避免GET的倾向。

为什么GET参数应成为url字符串的一部分，并且POST参数应成为请求正文的一部分，是否有任何充分的理由。

我的问题是：

1. 不应允许任何身体或网址字符串使用 方法？为什么GET参数必须在url中。
2. 有没有办法用身体中的参数实现GET（即使是从其他客户端...而不是浏览器）？

（问题更多地涉及REST，但通常也涉及HTTP）

更新：这里有一个更详细的讨论： HTTP GET with request body

Answer 1

基于浏览器和服务器的URL长度限制限制了可以放入URL的内容量。请求正文没有这样的限制。 URL也受限于允许的字符数，特殊字符被转换为其ascii等价物。

GET操作通常（并且具体地）用于检索信息，并且通常可以使用相对较小的搜索项集来参数化，倾向以适合简单的密钥=可以在URL查询中轻松编码的值方案。

POST具有更广泛的应用程序，通常用于将持久性数据发送到服务器（事实上，规范性地说GET不应该用于此目的）。如果您考虑使用网络表单，例如用户注册，则可能包含您希望其他用户查看的名称，地址，电子邮件地址，生物，以及您网页的网址。无论是数量还是内容形式，这都不适合包含在URL中。

使用POST和GET的URL实际上是为了保持常规的一致性，并反映了各个用例的不同需求。没有理由POST不能使用URL来编码信息，除了在很多情况下URL不适合POST内容，因此为了保持一致性，主体用于POST，而GET受到限制到URL以反映在给定一组输入参数的情况下从特定提供者检索内容的隐含“功能”合同。

Answer 2

GET和POST都可以使用URI中的参数。这里没有限制。

只有POST才能使用有效负载中的参数。从理论上讲，GET可以有一个有效载荷，但实际上它会被忽略，并且可能在传输过程中丢失（破坏的HTTP堆栈或中介）。

Answer 3

HTTP RFC定义GET，使其由UrL abd其他标头组成，并由两个换行符聊天终止。 URL方案由RFC定义，以包含用于将参数作为URL的一部分传递的特殊格式。 Web服务器和浏览器的设计符合这些标准，因此它们都是定义的标准和事实标准。

理论上，标头可用于在客户端和服务器之间传递参数。除了cookie，这是大多数客户端无法提供的非标准行为。

HTTP POST由RFC定义为包含与GET相同的URL和标头，以及包括POSTDATA部分，与标题分隔两个换行符并以两个换行符结尾（iirc）。 POSTDATA SECTION是专门定义的，允许cliebt将参数传递给服务器。

您尝试向您的GET请求添加POSTDATA部分，但代理和服务器无法正确解释它 - 终止GET请求标头的两个换行符将被解释为完全终止GET请求。以下POSTDATA部分将被解释为格式错误的请求，并被抛出。您可以编写一个自定义Web服务器来处理您的自定义GET格式，但这不会修复它们之间的代理服务器，并且它不会被任何现有客户端使用。您可以创建一个自定义客户端，使用您的自定义GET请求与您的服务器通信，只要没有代理服务器，这个woukd就可以工作。

但是你不能通过HTTP进行通信，而是你发明的不同的自定义协议。并且只有您的软件会使用此自定义协议，因此您无法获得通常在使用HTTP时所需的互操作性。

Answer 4

您只需要了解这两种方法都是相似的。

您可以选择将参数编码为查询字符串或在请求正文中，这就是我们POST或GET的原因。

因此，当你问为什么GET被编码为查询字符串没有意义时，因为如果它们不是那么它们将成为POST参数。