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

Question

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

是否有充分的理由让 GET 参数应该成为 url 字符串的一部分而 POST 参数应该成为请求正文的一部分。

我的问题是：

1. 是否应该允许使用正文或 url 字符串作为任何 方法？为什么GET参数必须在url中。
2. 有没有办法在正文中实现带有参数的 GET（即使是来自 rest 客户端..而不是浏览器）？

（问题更多地与 REST 相关，但通常也与 HTTP 相关）

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

Answer 1

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

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

Answer 2

存在基于浏览器和服务器的 URL 长度限制，这些限制限制了可以放置在 URL 中的内容量。请求的正文没有这样的限制。该 URL 还限制了允许使用的字符，特殊字符被转换为它们的 ascii 等效字符。

GET 操作通常（并且规定性地）用于检索信息，并且可以通常使用相对较小的一组搜索词进行参数化，倾向于以适合简单的键=值方案，可以很容易地在 URL 查询中编码。

POST 具有更广泛的应用，通常用于将持久性数据发送到服务器（事实上，GET 不应该用于此目的）。如果您考虑使用 Web 表单，例如用于用户注册，它可能包含姓名、地址、电子邮件地址、您希望其他用户看到的个人简介以及您网页的 url 的字段。无论是内容量还是内容形式，这都不适合包含在 URL 中。

POST 使用正文，GET 使用 URL 确实是为了保持约定的一致性，反映了各个用例的不同需求。没有理由 POST 不能使用 URL 对信息进行编码，除了在许多情况下 URL 不适合 POST 内容，因此为了保持约定的一致性，正文用于 POST，而 GET 受到限制到 URL 以反映在给定一组输入参数的情况下从特定提供商检索内容的隐含“功能”合同。

Answer 3

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

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

HTTP POST 由 RFC 定义为包含与 GET 相同的 URL 和标头，以及包含一个 POSTDATA 部分，该部分与标头之间用两个换行符分隔，并由两个换行符 (iirc) 终止。 POSTDATA SECTION 是专门定义的，以允许客户端将参数传递给服务器。

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

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

Answer 4

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

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

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