免责声明：这是针对Prestashop 1.5，但如果答案是：“这在版本1.x中得到修复”，那么我将提出请愿更新我们的商店 . 我也将它标记为REST因为我认为我已经足够解释它所以你不需要Prestashop的实际经验来理解它 .
所以在Prestashop中我们有这个Web服务，它缺乏对 search by category 之类的用例的支持 .
1. Let's say you want to get all the products from categories 1, 3 and 17:
那么解决方案是什么？那么，你可以在这个答案中做点什么：https://stackoverflow.com/a/34061229/4209853
如果您从第1类，第3类和第17类获得所有产品，那么您再次要求按照这些ID过滤产品 .
'filter[id]' => '['.implode('|',$productIDsArrayIGotBefore).']',
它是丑陋的，20世纪的，但是......如果它完成了工作......除了它没有 . 你知道，这是一个获取资源的呼吁，某个地方有人决定：
嘿，我们有所有这些好的HTTP动作动词，所以让我们将它们用于REST CRUD接口：POST为C，GET为R，PUT为U和DELETE为D. Neat .
这很好，但是当与Prestashop的Web服务缺乏表现力相结合意味着它很容易碰到，你猜对了吗？是的，414 .
Error HTTP 414 Request URI too long
我们都知道修改Apache以便它接受更长的请求URI是一个整洁的可扩展解决方案 .
所以我们可以尝试拆分数组并进行多次调用，这只是概念上的呃 . 这不仅仅是因为多次查询的性能受到影响，还因为我们需要考虑连接的所有ID的字符数，以便计算我们可以（安全地）在一次调用中请求的数量 . 所有这些都会有自己的警告，例如：
2. What if we want to also filter them e.g. active=1?
现在我们正在乘车，因为我们事先无法知道需要拨打多少电话 .
我们来定义：
-
N是我从类别中获得的ID -
n是我可以安全要求的IDS号码 -
T是我想要的（过滤的）产品数量 -
t是我已经拥有的（已过滤）产品 -
k是我们从通话中收到的（已过滤）产品
所以我们最终得到的结果如下：
do{
n0= max(T-t, n);
k= get(products, n0);
t +=k;
}while(count(k)!=0 and count(t)<T and !empty(N))
..这只是......疯子 .
我能想到的唯一优雅的解决方案是创建一个新的Prestashop Web服务，它充当包装器，通过POST接收请求并将其转发到Prestashop服务 .
但是，之前...你有一个更好的解决方案使用某种RESTomancy我可能会失踪？