首先承认超过GET的URL总长度的情况确实可能存在的，一个比较典型的场景就是多选id，鬼知道一个变态能选出多少个来

当然一个合理的应用不应该让这种情况出现，毕竟用手勾选到能超过URL的长度限制应该是会抽筋的，我们亲爱的产品组应该为用户着想

至于“全选”和“全选后取消几个”这种场景，其一我很怀疑后者的用户场景是否真的存在，其二可以使用全选和反选标记来给予实现，也并不是什么麻烦事儿

继续说真的超过了URL长度限制怎么办，第一反应自然是拿POST来玩，但是使用POST除去教条式的语义性和REST规范之外，一个很严重的影响是无法使用HTTP缓存

当然这个也不是什么大问题，毕竟99.99%的应用是不会精心设计HTTP缓存的（是的这句话是在喷包括自己在内的很多工程师），所以搜索这种场景从一开始就几乎是没有HTTP缓存支持

那如果我还是想要缓存，还是想要遵守REST规范使用GET怎么办呢？这里有一个理论主义的玩法

假设我们对商品进行检索，有这样的URL：

然后我们再在其下创建一个叫“查询条件”的集合：

我们使用POST来创建一个查询条件

创建了之后自然会返回一个id，所以这个请求的响应大概就能这样：

然后再拿这个id去查询，查询视为对“查询”这个集合的单个实体获取

响应自然就是查询应该有的结果，也可以把那个POST请求的响应搞成302以减免前端再编码发下一个请求的工作量

这样可以有效利用缓存，而且完全符合REST的规范，但代价挺大：

除此之外，后端可以做一些工作，如相同的查询可以直接共享之前的id，以便更好地使用缓存

前面

有质疑对查询建立实体是否合理，我这里很明确地说，REST就是这么玩的，一切皆资源，一切皆可以是实体，只不过也不能像

那样强行把搜索搞成POST说那是资源的创建，资源还是要有集合+对集合的操作组成的，表面文章还是得做一做

回头再来说，其实无法很好地处理这种问题，无法很顺理成章地得出一个合理的解决方案，其根本原因是大家的应用都不是在玩REST设计，只是在实现层面上“看着像REST”而已，你不是使用资源进行系统建模，不是以资源的角度来进行设计，自然遇到问题不会从资源的角度去考虑，最后和REST需要的资源第一位的观点冲突，把自己绕死

这种伪REST其实很要不得，要么你就把REST丢掉，只留下“URL好看点不错”这样的目标，要么你就玩纯粹基于资源的设计和实现