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

Question

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

左窗格:过滤面板.

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

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

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

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

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

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

可能的解决方案:考虑到我们不能直接在查询参数中添加普通字符串,因为不同浏览器的URL长度限制(注意:规范不限制HTTP Get请求的长度,但不同的浏览器实现自己的限制),我们可以使用类似于消息摘要或散列(将任意长度的输入转换为固定长度的输出)并将其保存在DB中以供服务器理解请求并提供内容.这只是一个想法,我不确定这是否是解决这个问题的理想方案.

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

• amazon.com,newegg.com - >使用散列网址.
• kayak.com - >因为他们有非常明确的关键字,他们使用简短的形式,如印度的IN,班加罗尔的BLR等,并将其与否定逻辑相结合,以进一步优化最大网址长度.没有选中,但在大量选择过滤器后理想情况下会中断.
• flipkart.com - >将字符串直接附加到查询参数,并在违反限制后中断.验证了这个.

Answer 1

针对@cauchy的回答，我们需要区分哈希和加密。

散列

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

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

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

加密

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

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

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

您在上面的评论中提到

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

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

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

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

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

1. 保留所有现有支持的过滤器的持久记录。
2. 在构建时，检查是否有任何新的过滤器。如果是这样...
   1. 将这些过滤器添加到步骤 1 中的记录中。
   2. 散列所有新的过滤器排列（仅包含新过滤器的排列）并将其存储在散列数据库中
3. 检查是否有任何过滤器已被移除。如果是这样...
   1. 从步骤 1 的记录中删除这些过滤器。
   2. 找到包含这些过滤器的排列的所有哈希值，并且......
      • 从数据库中删除这些哈希值（弱永久链接），或者
      • 将该哈希指向数据库中合理的替代哈希（强永久链接）