HTTP GET 和 POST 语义和限制

Question

本周早些时候，我不得不做一些感觉像是违反语义的事情。让我解释一下。

我正在制作一个简单的 AJAX 客户端应用程序，它使用给定数量的参数向服务发出请求。由于整个应用程序基本上是只读的，我认为使用 HTTP GET 是可行的方法。我必须传递的一些参数很简单(例如排序顺序或页码)。

但是，其中一个必需参数的长度可能是可变的，这让我很担心。因为我在 GET 请求的查询字符串中对所有参数进行编码，所以在我看来这放置了一个不必要的 upper limit of (roughly) 2000 characters for the request URL。 .不管怎样，我不喜欢看到 500 个字符长的请求 URL。

因此，由于 POST 请求没有这样的限制，我决定切换。但这感觉不对。我的印象是 POST 表示数据修改 - 但我将它用于简单的只读请求。

有更好的方法吗？要执行带有许多参数的 GET？我听说过一种方法 - 您对 参数 本身执行初步 POST，然后执行 GET。但是，这种技术还有很多不足之处。

但回顾这个具体案例，HTTP 请求方法的真正语义和限制是什么？ 为什么 GET 不支持任何类型的参数负载？在 URL 中使用查询字符串对我来说几乎是一种破解。

Answer 1

关于这个问题的几点说明:

• HTTP 规范 (RFC 2616) 不禁止 GET 请求带有参数，因此这与 HTTP GET 本身的语义无关。但是，许多 HTTP 堆栈(用于客户端、服务或代理)禁止在 HTTP 请求中使用主体，您不能使用它们的事实主要是一个实现细节(非常普遍)，而不是 HTTP GET 请求的语义问题
• 同样，RFC 中也没有指定 URI(或查询字符串)长度的限制。它主要是由多个 HTTP 服务器堆栈实现的安全缓解措施，以防止不良客户端消耗服务器资源(例如，在 IIS/ASP.NET 中，默认限制为 2k，但您可以通过 web.config 中的某些元素增加它)。同样，这不是语义问题，而是实际问题。
• 如果您遵循 REST 理念，POST 请求确实指示数据修改，但是有许多用于只读操作的 HTTP POST 请求示例。 SOAP 在其所有请求中都使用 POST，而不管它调用的操作是“安全”操作还是“修改”操作。因此，您也可以将 POST 用于这些操作。但是，如果偏离 REST(和“规范的”HTTP)用法，您将失去该协议(protocol)的一些功能，例如可应用于 GET 请求但不适用于 POST 的缓存。
• 您使用两个请求(带参数的 POST + GET 以“获取”结果)的示例似乎有些矫枉过正。正如我提到的，POST 请求并不一定意味着修改资源，因此当一个请求就足够时，您不必创建新的“协议(protocol)”(POST+GET) 来访问您的操作。