REST 接口和搜索答案

【问题标题】：REST Interface and SearchREST 接口和搜索
【发布时间】：2016-02-28 22:44:48
【问题描述】：

我正在编写 REST API 规范并努力寻找搜索功能的正确表示。

搜索通常需要 1 或 2 个主要（非可选）参数以及 10-15 个可选参数（可能是过滤器，也可能不是过滤器）并点击 solr/elasticsearch 实现以获取内容

我已阅读 How to design RESTful search/filtering? 和 http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api 并试图将“搜索”本身作为资源公开并使用 JSON 正文进行 POST。但是，当更可接受的方法是查询参数和 GET 时，感觉不正确（和 RESTful）

此 API 将输入的 UI 实际上是一个搜索网站。因此，典型的用户场景是用户搜索某物，一旦返回列表，用户就可以深入到每个元素/项目。该项目不会是平面物体。这将是一个具有嵌套资源的复杂对象，我打算通过遵循 HATEOAS 来公开它。

我不完全确定如何进行此操作，并希望获得一些反馈/答案。

非常感谢

编辑

我最终按照用户 Qwerty 的建议进行了操作 RESTful URL design for search

感谢所有评论的人。

【问题讨论】：

你为什么不直接选择GET /search?param1=x&param2=y？如果你知道你将使用什么根实体，你当然可以用它代替search，例如GET /users?param1=x...
我只是有点担心这会对 url 的长度造成什么影响。我希望使用请求正文来传递复杂的参数。例如，我可以有多个参数，它们是数组（或逗号分隔的 id）。在这种情况下，端点 url 会变得太长。我还想使用查询字符串来传递与“排序”/“排序依据”等相关的参数，但将“搜索”参数保留在正文中。
即使网址可能很长，但如果它们都是可选的，那么我认为这不是问题。对我来说，这比用POST 搜索更有意义。如果一个端点上的逻辑真的太复杂，也许您可以考虑将其拆分为不同的资源？

【解决方案1】：

我最近遇到了类似的问题，并且：

编辑

当谈到 303 和 REST 时，我错了 - 请参阅 here。

【讨论】：

感谢您的回复。您对 api/filters 端点所做的事情非常有趣。这是否意味着对于您提出的每个搜索请求，您最终都会发出两个 http 请求（本质上），一个用于创建过滤器，另一个用于实际过滤？您还将创建的过滤器存储在哪里。不确定这是否是一个有效的问题。如果不能，请详细说明您的设计。谢谢
@nesh_s，是的，肯定有两个请求。但取决于第一个请求的状态代码，如果或多或少明确，则取决于第二个请求。我个人将创建的过滤器存储在与创建特定过滤器的用户相关的数据库中。但是您可以将它们存储在任何临时商店中——这仅取决于以后是否需要它们。整个想法是让端点更加 RESTful。后端过滤器会发生什么进入后台。
非常有帮助。谢谢你的评论。我最终做了一个 GET，并在 json 中传递搜索条件，然后在查询字符串中传递。