我想知道这是否是一个错误，但现在我对所有搜索 URL 都使用 GET。原因是，通过 GET Url，用户可以简单地复制地址栏上的链接并轻松共享或保存。例如，Google 似乎也使用 GET Url（表单）。
由于它是一个带有过滤器、排序器等的搜索表单，因此生成的 URL 的长度可能是不可预测的。我担心 URL 可能超出长度限制的边缘情况。可能的解决方案是实际 POST 数据，然后根据该数据生成唯一的哈希值，然后使用它作为搜索的 URL。例如，该解决方案确实需要将实际的表单数据保存到数据库，然后在每个搜索请求上重新查询它，这似乎很浪费。
我想知道还有什么我还没想到的办法吗？
编辑：我想感谢您在这里的所有回答，他们帮助了很多。我将在下面总结我为解决此问题所做的工作，希望对其他人有所帮助：
- 正如所指出的，如果 URL 太长（超过 2000 个字符），那么我可能做错了什么。所以我回去重新审视了我的算法，并设法将我必须通过 GET 字符串传递的信息削减了一半以上（以前，它可以轻松获取超过 500 个字符，这让我很担心）
- 我还对我的字符串进行了 json 化。原因是深层嵌套数组在查询字符串上效果不佳，通过 json化数组，我实际上得到了一个更短且更易于阅读的结果
- 还有另一种解决方案，那就是编写自己的解析器，例如，如果您想获得更短的网址，您可以编写：category=1,2,3,4,5，因为您已经知道您的查询结构，所以您可以这样做在你的后端进行解析。这需要更多的工作，所以我还没有尝试过，直到我真的需要这样做
- 我还没有尝试过哈希/令牌路线，但我相信如果您真的必须处理大量输入，这也是一个很好的解决方案。您可以 POST 输入，然后发回哈希字符串标记以用作搜索 URL。
First of all, according to this Stack Overflow answer https://stackoverflow.com/a/417184/1709587, you're fine up until 2000 characters1.
一旦达到该限制，如果您想保持 URL 的可共享性，我可以看到以下几种选择：
- 正如您所建议的，使用 POST 请求来存储实际查询并将其与哈希关联，然后使用后续 GET 请求来运行查询并检索结果。
- 压缩客户端的查询字符串并在服务器端解压缩。
让我们考虑一下这些方法的相对优点。
支持哈希...
- 您可以将 URL 保持任意小（并且具有固定长度，例如 12 或 16 个字符），而如果您采用压缩路线，则可能会得到更长（因此更难看）的 URL。
- 您的搜索可以变得任意长——如果您出于某种不正当的原因需要它们，它们可能是巨大的数千页文档。 （你可能不知道。）
- 您可以在 PHP 中轻松地执行此操作hash http://php.net/manual/en/function.hash.php，而使用什么工具进行压缩方法则不太明显。
有利于压缩...
- 表现。每当用户进行搜索时，散列方法都需要向服务器发出两个请求，这不可避免地会对用户可见的性能产生影响，因为每次搜索都要付出与服务器额外往返的延迟成本。 （好吧，如果您对客户端进行散列，并在知道计算出的散列是否已存储之前尝试使用计算出的散列进行 GET，那么您可以将其减少到 1 个对某人之前执行过的搜索的请求，但这样做的代价是新的搜索需要3要求。）
- 您不需要在任何地方存储哈希到查询的映射。根据您的具体情况，当表有数亿行时，将这些数据放入数据库可能会在数年后成为性能陷阱或磁盘使用问题。
其中一些因素可能与您无关，具体取决于您的具体情况；我让你权衡你的优先事项。
如果你想走压缩路线，我不知道该向你推荐什么工具。如何压缩URL参数 https://stackoverflow.com/questions/21802866/how-to-compress-url-parameters可能是一个开始寻找的好地方。或许还可以考虑https://github.com/pieroxy/lz-string https://github.com/pieroxy/lz-string压缩https://github.com/nullpunkt/lz-string-php https://github.com/nullpunkt/lz-string-php解压。
1 Note that a 2000 character URL is quite long. Are your URLs really this long?
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
