http - 我如何处理 HTTP GET 查询字符串长度限制并仍然想成为 RESTful？

Question

如 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> .这是行不通的，因为查询字符串的长度不是无限的。

我有点不解...

Answer 1

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。