如中所述http://www.boutell.com/newfaq/misc/urllength.html 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规范实际上建议在向资源发送数据时使用 POST http://webee.technion.ac.il/labs/comnet/netcourse/CIE/RFC/1945/42.htm用于计算。
您的搜索看起来像是一种计算，而不是资源本身。如果您仍然希望搜索结果成为资源，您可以做的就是创建一个令牌来标识该特定搜索结果并将用户代理重定向到该资源。
然后，您可以在一段时间后删除搜索结果标记。
Example
POST /search
query=something&category=c1&category=c2&...
201 Created
Location: /search/01543164876
then
GET /search/01543164876
200 Ok
... your results here...
这样，浏览器和代理仍然可以缓存搜索结果，但您使用 POST 提交查询参数。
EDIT
为了澄清，01543164876这里代表代表您的搜索的资源的唯一 ID。这两个请求基本上意味着：使用这些条件创建一个新的搜索对象，然后检索与创建的搜索对象关联的结果。
该ID可以是为每个新请求生成的唯一ID。这意味着您的服务器将泄漏“搜索”对象，您必须使用缓存策略定期清理它们。
或者它可以是实际代表用户所要求的搜索的所有搜索条件的散列。这允许您重用 ID，因为重新创建搜索将返回可能（或可能未）已缓存的现有 ID。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
