如 http://www.boutell.com/newfaq/misc/urllength.html 中所述, HTTP 查询字符串有长度限制。它可以被客户端(Firefox、IE、...)、服务器(Apache、IIS、...)或网络设备(应用防火墙、...)限制。
今天我遇到了一个搜索表单的问题。我们开发了一个包含很多字段的搜索表单，此表单作为 GET 请求发送到服务器，因此我可以为结果页面添加书签。
我们的字段太多以至于我们的查询字符串有 1100 字节长，而且我们有一个防火墙可以丢弃超过 1024 字节的 HTTP GET 请求。我们的系统管理员建议我们改用 POST，这样就没有限制了。
当然，POST 可以，但我真的觉得搜索是 GET 而不是 POST。所以我想我会检查我们的字段名称以确保查询字符串不会太长，如果我不能，我会务实地使用 POST。
但是RESTful服务的设计有缺陷吗？如果 GET 请求的长度有限，我该怎么做才能将大对象发送到 RESTful web 服务？例如，如果我有一个基于文件进行计算的程序，并且我想提供这样的 RESTful web 服务:http://compute.com?content=<base64 file> .这是行不通的，因为查询字符串的长度不是无限的。
我有点不解...
最佳答案
HTTP 规范实际advises to use POST when sending data to a resource用于计算。
您的搜索看起来像是一种计算，而不是资源本身。如果您仍然希望搜索结果成为资源，您可以做的是创建一个 token 来标识该特定搜索结果并将用户代理重定向到该资源。
您可以在一段时间后删除搜索结果标记。
示例
POST /search
query=something&category=c1&category=c2&...
201 Created
Location: /search/01543164876
然后
GET /search/01543164876
200 Ok
... your results here...
这样，浏览器和代理仍然可以缓存搜索结果，但您使用 POST 提交查询参数。
编辑
需要说明的是，此处的 01543164876 表示表示您的搜索的资源的唯一 ID。这 2 个请求基本上意味着:使用这些条件创建一个新的搜索对象，然后检索与创建的搜索对象关联的结果。
此 ID 可以是为每个新请求生成的唯一 ID。这意味着您的服务器将泄漏“搜索”对象，您将不得不使用缓存策略定期清理它们。
或者它可以是所有实际代表用户要求的搜索的搜索条件的散列。这允许您重复使用 ID，因为重新创建搜索将返回可能(或可能未)已缓存的现有 ID。
关于http - 我如何处理 HTTP GET 查询字符串长度限制并仍然想成为 RESTful？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4203686/