我想知道在创建本质上相当于 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 的解决方案。