使用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