【发布时间】：2015-02-12 11:24:08
【问题描述】：
我想知道这是否是一个错误，但现在我对所有搜索 URL 都使用了 GET。原因是使用 GET Url 用户可以简单地复制地址栏上的链接并轻松共享或保存。例如，Google 似乎也使用 GET Url（表单）。
由于它是一个带有过滤器、排序器的搜索表单，因此生成的 URL 的长度可能无法预测。我担心 URL 可能超过长度限制的边缘情况。可能的解决方案是实际发布数据，然后根据该数据生成唯一的哈希，然后将其用作搜索的 URL。例如，此解决方案确实需要将实际表单数据保存到数据库中，然后在每次搜索请求时重新查询它，这似乎很浪费。
不知道有没有其他的方法我还没有想到？
编辑：我想在这里感谢您的所有回答，他们帮助很大。我将在下面总结我为解决此问题所做的工作，希望对其他人有所帮助：
- 正如所指出的，如果 URL 太长（超过 2000 个字符），那么我可能做错了什么。所以我回去重新审视了我的算法，并设法将我必须通过 GET 字符串传递的信息减少了一半以上（以前，它很容易得到超过 500 个字符，这让我很担心）
- 我还对我的字符串进行了json化。原因是深层嵌套数组在查询字符串上效果不佳，通过对数组进行 json 化，我实际上得到了一个更短且更易于阅读的结果
- 还有另一种解决方案，即编写您自己的解析器，例如，如果您想获得更短的 url，您可以编写：category=1,2,3,4,5 并且您已经知道您的查询结构您可以在后端进行解析。这需要更多的工作，所以我还没有尝试过，直到我真的不得不这样做
- 我还没有尝试过散列/令牌路由，但我相信如果你真的必须处理大量输入，它也是一个很好的解决方案。您可以发布输入，然后发回哈希字符串令牌以用作搜索 URL。
【问题讨论】：
-
HTTP 协议中没有设置“最大”长度，但是浏览器有一些限制。但是，这些数字确实很大，我不会担心。有关 url 长度的更多信息可以在这里找到：boutell.com/newfaq/misc/urllength.html
-
如果您不需要用于 GET 的数据库，您将不需要用于 POST 的数据库。为什么不将这些数据存储在会话中？
-
@Jonast92 谢谢，我搜索的时候没发现，我看看有没有好的解决方案，然后关闭这个问题
-
@SpencerWieczorek 在会话中保存 url 意味着用户无法共享 url，这在我的特定情况下是不可取的。
-
@Jonast92 'duplicate' 冗长乏味，并且接受的答案是使用 POST 请求而不是 GET 的方法，这里的提问者给出了想要避免的充分理由。我投票保持开放。