在我的基于反应的单页面应用程序中，我的页面分为两个窗格。
左窗格：过滤面板。
右窗格：网格（包含通过应用过滤器的数据的表格）
总之，我的应用程序与amazon.com非常相似。默认情况下，当用户在浏览器中点击应用程序的根端点（/）时，我会从服务器获取最近7天的数据并将其显示在网格中。
过滤器面板有两个过滤器（例如，时间过滤器用于获取落在指定时间间隔内的数据，ID用于搜索具有特定ID的数据等）以及附加在过滤器面板标题中的搜索按钮。点击搜索按钮通过在帖子表单体内提供选定的过滤器来对服务器进行调用，服务器返回与传递的过滤器匹配的数据，我的前端应用程序显示从网格内的服务器返回的这些数据。
现在，当某人点击过滤器面板中的搜索按钮时，我想在网址的查询参数中反映所选过滤器，因为它可以帮助我与我网站的其他用户分享这些网址，以便他们可以看到过滤器我应用并查看网格内仅与这些过滤器匹配的数据。
问题在于，如果在搜索按钮上单击，我使用http get查询参数，由于不同浏览器对URL长度的限制，我将最终破坏应用程序。
请建议我使用正确的解决方案来创建此类网址，以帮助我在过滤器面板中设置所选过滤器，而不会在我的应用程序中造成任何副作用。
可能的解决方案：考虑到由于不同浏览器的URL长度限制，我们无法在查询参数中直接添加普通字符串这一事实（注意：规范不限制HTTP Get请求的长度，但不同浏览器实现自己的限制），我们可以使用消息摘要或散列（将任意长度的输入转换为固定长度的输出）并将其保存在DB中以供服务器理解请求并提供内容。这只是一个想法，我不确定这是否是解决这个问题的理想方法。
其他频繁使用的网站的行为：
答案 0 :(得分：3)
让我们分析您的问题和解决方案。 问题：您需要一个URL，其中包含有关应用过滤器的信息，以便在您共享该URL时，用户不会登陆任意页面。
解决方案：
1）附加使用URL的过滤器。为此，您需要缩短过滤器类型的键和过滤器的值，以使每个过滤器的URL长度不会超过。
缺点：这不是最可靠的解决方案，因为过滤器增加URL长度的数量必须增加其他选项。
2）使用URL附加应用过滤器（哈希）的唯一键。为此，您需要在服务器和客户端上进行一些更改。在客户端，您将需要一种编码算法，该算法将应用于特定哈希的过滤器转换在服务器端，您将需要解码算法，将唯一散列转换为应用的过滤器。现在客户端每当有这样的URL被命中时，你就可以进行POST api调用，这个哈希给你应用的过滤器数组，或者在客户端只有逻辑转换这个哈希。
在componentWillMount中执行此操作以避免任何副作用。
我认为第二种解决方案在几乎所有情况下都具有可扩展性和高效性。
答案 1 :(得分：3)
为响应@cauchy's answer，我们需要区分哈希和加密。
哈希必然是不可逆转的。为了将散列映射到特定的过滤器组合，您需要
对于绝大多数情况，选项1将会太慢。根据过滤器和选项的数量，选项B可能需要相当大的地图，但它仍然是您的最佳选择。
在此方案中，服务器将其公钥发送到客户端，然后客户端可以使用它来加密其过滤器选项。然后，服务器将使用其私钥解密加密数据。这很好，但您的加密数据不会固定长度。因此，当选择更多选项时，会遇到不确定参数长度的相同问题。
因此，为了确保您的网址不包含任意数量的过滤器和选项，您需要在服务器上维护hash-＆gt;选择的映射。
如果我们使用一些持久性存储来保存此哈希与实际过滤器之间的映射，我们理想地希望隔离长期存在的永久链接＆＃34;来自短暂的短暂URL，并使用这种理解有效地使短暂的哈希值过期。
您可能在服务器上有一项服务，可以处理您在应用程序中支持的所有过滤器。这里的诀窍是让该服务也管理hashmap。随着添加/删除更多过滤器和选项，服务将需要重新排列过滤器选择的每个排列。
如果您需要对固定链接的强大支持，那么每当您删除过滤器或选项时，您都希望保持过期＆＃34;过期＆＃34;散列并更改其映射以指向合理的替代散列。
有很多选项，但我通常更喜欢构建时间。如果您正在使用Jenkins，Travis，AWS CodePipeline等CI解决方案，那么您可以添加构建步骤来更新您的数据库。基本上，你要去......