REST API的复杂请求

Question

我想知道在创建本质上构成BI工具的东西时是否可以遵守REST原则。

在我的场景中，我具有100,000个ID的高数据量（坦白地说，比这还要多，但是为了这个示例，让我们继续。） 这些以传统表的形式呈现，当访问大数据集（例如分页）时，该表允许必要的功能。 用户还可以按其中一个或多个ID进行过滤，以便在他们认为合适的情况下向下钻取数据集。

从理论上讲，用户可能希望对100个ID进行过滤，从而使GET URI变得异常长。 据我了解，这将破坏REST API的资源标识原理。 更不用说可能会遇到某些浏览器在GET请求中字符限制的问题，因为ID可能很长。 通常，我只使用POST，因为我可以在主体中添加所有应用的过滤器并在服务器上生成where子句。

由于REST API中的POST应该

在集合中创建一个新条目。

从定义上看，至少对我来说，生成类似这样的复杂查询将意味着REST API是不可能的。 或这是否意味着我正在错误地解决该问题（完全合理）。

在我的场景中，由于参数的潜在长度，似乎根本无法使用GET。 因此，我被迫使用POST。 尽管我使用POST似乎违反了REST风格，但这并不是世界末日。 我主要只是想仔细检查我是否没有丢失任何东西，并且没有使用GET的解决方案。

Answer 1

遵循资源原则，进行类似资源的搜索。 将您的ID发布到该端点的正文中，它将为您准备结果列表，并将您重定向到searchresults / {id}。

参见例如： https : //gooroo.io/GoorooTHINK/Article/16583/HTTP-Patterns---Bouncer/25829#.W3aBsugzaUk