我们假设我们正在设计REST API。我们有一些实体，我们称之为foo
因此，返回根据某些谓词过滤的foo个实体列表的端点如下所示：
GET /foos?filtering-parameters-here
但问题是filtering-parameters有效载荷的大小可能很大。在某些情况下，它可能很容易超过6-7kb。
一些客户端（浏览器）正在修剪URL，以防它的大小。
“明显”的解决方案是将其更改为POST并在正文中发送参数。但它会使端点在语义上不干净。
那么正确的RESTful方式是什么？
答案 0 :(得分：4)
我听说过在这种情况下使用POST的建议，但不仅仅是接受参数。
相反，使用复杂的过滤数据作为邮件正文来触发POST请求，并且可预测创建资源;我们称之为search：
POST /search HTTP/1.1
响应通过Location标识结果集：
Location: http://example.com/search/798342
可以针对该位置发出后续GET请求，并返回结果集。当结果集可能需要一些时间来生成（，这可能是复杂的过滤规则的情况下）并保持与HTTP的期望保持一致时，这非常适用 。 p>
GET /search/798342 HTTP/1.1
如果搜索结果尚未就绪，请生成404。
与其他任何事物一样，搜索可以/应该表示为资源。另一个好处是缓存。如果缓存复杂操作的结果，则可以从搜索结果集资源传达缓存生存期。