javascript - 在单页应用程序中创建临时 URL

Question

在我基于 React 的单页应用程序中，我的页面分为两个 Pane 。

左 Pane :过滤器面板。

右 Pane :网格(包含通过应用过滤器的数据的表格)

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

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

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

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

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

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

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

• amazon.com、newegg.com -> 使用哈希 url。
• kayak.com -> 因为他们有非常明确的关键词，他们使用INDIA 的缩写形式，Bangalore 的 BLR 等缩写形式，并结合使用这与否定逻辑进一步优化最大 url 长度。不是已检查，但理想情况下这会在选择大量过滤器后中断。
• flipkart.com -> 将字符串直接附加到查询参数并中断突破限制后。验证了这一点。

Answer 1

回应@cauchy's answer ，我们需要区分哈希和加密。

散列

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

1. 为每个请求散列服务器上过滤器的每个排列，以尝试匹配请求的散列(计算密集型)或
2. 在服务器上存储 HashMap 到过滤器组合(内存密集型)。

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

加密

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

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

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

您在 your comment above 中提到

If we use some persistent store to save the mapping between this hash to actual filters, we would ideally want to segregate long-lived "permalinks" from short-lived ephemeral URLs, and use that understanding to efficiently expire the short-lived hashes.

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

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

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

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

1. 保留所有现有受支持过滤器的持久记录。
2. 在构建时，检查是否有任何新过滤器。如果是这样的话...
   1. 将这些过滤器添加到第 1 步的记录中。
   2. 散列所有新的过滤器排列(仅包含您的新过滤器的排列)并将它们存储在散列数据库中
3. 检查是否删除了任何过滤器。如果是这样的话...
   1. 从第 1 步的记录中删除这些过滤器。
   2. 找到包含这些过滤器的排列的所有散列，或者...
      • 从数据库中删除这些散列(弱永久链接)，或者
      • 将该散列指向数据库中的合理替代散列(强永久链接)