在我的基于反应的单页面应用程序中，我的页面分为两个窗格。

左窗格：过滤器面板。

右窗格：网格（包含通过应用过滤器的数据的表）

总之，我有一个看起来与 amazon.com 非常相似的应用程序。默认情况下，当用户在浏览器中点击应用程序的根端点 (/) 时，我会从服务器获取最近 7 天的数据并将其显示在网格内。

过滤器面板有几个过滤器（例如，时间过滤器用于获取指定时间间隔内的数据，ID 用于搜索具有特定 ID 的数据等）以及附加在过滤器面板标题中的搜索按钮。点击搜索按钮通过在帖子表单主体内提供选定的过滤器来对服务器进行帖子调用，服务器返回与传递的过滤器匹配的数据，我的前端应用程序显示从网格内的服务器返回的数据。

现在，当有人点击过滤器面板中的搜索按钮时，我想在 URL 的查询参数中反映所选的过滤器，因为这将帮助我与网站的其他用户共享这些 URL，以便他们可以看到我应用的过滤器和仅查看与这些过滤器匹配的网格内的数据。

这里的问题是，如果在单击搜索按钮时，我使用带查询参数的 http get，由于不同浏览器对 URL 长度施加的限制，我最终会破坏应用程序。

请建议我正确的解决方案来创建此类 URL，这将帮助我在过滤器面板中设置选定的过滤器，而不会在我的应用程序中造成任何副作用。

可能的解决方案：考虑到由于不同浏览器的 URL 长度限制，我们无法直接在查询参数中添加纯字符串（注意：规范不限制 HTTP Get 请求的长度，但不同的浏览器实现自己的限制），我们可以使用类似 message摘要或散列（将任意长度的输入转换为固定长度的输出）并将其保存在数据库中，以便服务器理解请求并返回内容。这只是一个想法，我不确定这是否是解决这个问题的理想方法。

其他频繁使用的网站的行为：

• amazon.com、newegg.com ->使用哈希 url。
• 皮划艇网站 ->因为他们有非常明确的关键字，所以他们使用 缩写形式，例如 IN 代表印度，BLR 代表班加罗尔等，然后组合起来 这与否定逻辑进一步优化最大 url 长度。不是 检查过，但理想情况下，在选择大量过滤器后，这会中断。
• Flipkart.com ->将字符串直接附加到查询参数并中断 突破限制后。验证了这一点。

作为回应@cauchy的回答 https://stackoverflow.com/a/48125831/2479481，我们需要区分hashing and 加密.

Hashing

哈希必然是不可逆的。为了将哈希映射到特定的过滤器组合，您需要

1. 对每个请求对服务器上的过滤器的每个排列进行哈希，以尝试匹配请求的哈希（计算密集型）或
2. 在服务器上存储哈希到过滤器组合的映射（内存密集型）。

对于绝大多数情况，选项 1 会太慢。根据过滤器和选项的数量，选项 B 可能需要相当大的地图，但它仍然是您的最佳选择。

加密

在此方案中，服务器将其公钥发送给客户端，然后客户端可以使用它来加密其过滤器选项。然后，服务器将使用其私钥解密加密数据。这很好，但是您的加密数据将不是固定长度的。因此，随着选择更多选项，您会遇到相同的参数长度不确定的问题。

因此，为了确保您的 URL 对于任意数量的过滤器和选项来说都是简短的，您需要在服务器上维护 hash->selection 的映射。

我们应该如何处理永久链接和临时链接？

你提到的你上面的评论 https://stackoverflow.com/questions/46629900/creating-temp-urls-in-single-page-applications/48157489#comment83228591_48125831

如果我们使用一些持久性存储来保存此哈希值与实际过滤器之间的映射，那么理想情况下，我们希望将长期“永久链接”与短期临时 URL 分开，并使用这种理解来有效地使短期哈希值过期。

您可能在服务器上有一个服务来处理您的应用程序中支持的所有过滤器。这里的技巧是让该服务也管理哈希图。随着添加/删除更多过滤器和选项，服务将需要重新散列过滤器选择的每个排列。

如果您需要对永久链接的强大支持，那么每当您删除过滤器或选项时，您都需要维护“过期”哈希值并更改其映射以指向合理的替代哈希值。

我们什么时候更新数据库中的哈希值？

有很多选择，但我通常更喜欢构建时间。如果您使用的是 Jenkins、Travis、AWS CodePipeline 等 CI 解决方案，那么您可以添加构建步骤来更新数据库。基本上，你会...

1. 保留所有现有支持的过滤器的持久记录。
2. On build, check to see if there are any new filters. If so...
   1. 将这些过滤器添加到步骤 1 中的记录中。
   2. 散列所有新的过滤器排列（仅包含新过滤器的排列）并将其存储在散列数据库中
3. Check to see if any filters have been removed. If so...
   1. 从步骤 1 的记录中删除这些过滤器。
   2. Find all the hashes for permutations that include those filters and either...
      • 从数据库中删除这些哈希值（弱永久链接），或者
      • 将该哈希指向数据库中合理的替代哈希（强永久链接）