如何在后退/前进或刷新后保留数据表中的筛选器

我们使用DataTables作为我们的表，并且我们遇到了问题/不同意以某种方式保留以前应用于表的过滤器的历史记录，以便用户可以来回刷新这些过滤器。

现在，提出的一个解决方案是我将过滤器字符串保留在 URL 中，并将其作为 GET 请求传递，这将很好地与来回和刷新一起使用。但是由于我有非常自定义的过滤选项（嵌套的过滤器组），过滤器字符串变得很长，实际上太长了，由于长度限制，无法通过 GET 请求传递它。

因此，由于GET是不可能的，显而易见的解决方案是POST请求，这是我们不能达成一致的。

第一个解决方案是使用 POST 请求，并在每次我们尝试来回或刷新时都会收到"烦人"的弹出窗口。我们还打破了我们在整个网站中使用的 POST/重定向/GET 模式，因为不会有 GET。

优点：

• 简单的解决方案
• 没有对服务器的第二次请求
• 无需额外的数据库请求
• 无需其他数据库数据
• 仅在选择时将筛选器保存到数据库，以便可以随时重新应用它

缺点：

• 打破开机自检/重定向/获取模式
• 必须使用 pushState 推送 POST 数据（历史记录.js）
• 如何让刷新工作？

第二种解决方案是使用 POST 请求，服务器端将数据保存在数据库中，获取用于请求保存数据的 ID，返回它，然后客户端使用此 ID 执行 GET 请求，服务器端将其匹配回数据，返回正确的过滤器，从而保留 POST/重定向/GET 模式。此解决方案发出两个请求，并将用户使用的每个筛选器保存到数据库中。每个用户在数据库中只保存有限数量的"历史记录"过滤器，旧的过滤器在应用新过滤器时被删除。基本上，服务器端会通过将长数据保存到数据库来缩短您的 URL，就像 URL 缩短站点所做的那样。

优点：

• 保持开机自检/重定向/获取模式
由于
• 再次发送帖子数据，来回/来回刷新页面时没有弹出消息

缺点：

• 复杂的解决方案
• 对服务器的其他请求
• 对数据库的其他请求
• 数据库中的大量数据不会使用，除非用户来回或刷新页面

第三种解决方案将非常受欢迎，或者选择上述解决方案之一并理想地解释原因。