REST和复杂的搜索查询
我正在寻找一种在REST API中建模搜索查询的强大方法。
在我的api中，您可以使用查询参数在资源的URI中指定搜索条件。
例如：
/cars?search=color,blue;AND;doors,4 --> Returns a list of blue cars with 4 doors
/cars?search=color,blue;OR;doors,4 --> Returns a list of cars that are blue or have 4 doors
在服务器端，搜索字符串映射到所需的基础技术。 根据其余资源，这可以是SQL查询，Hibernate Criteria api，另一个Web服务调用，……
这2个例子很简单，但我还需要更复杂的搜索function，如子字符串搜索，日期之前/之后搜索，NOT，…
这是我认为的常见问题。 是否有我可以使用的库（或模式）：
- 将指定为字符串的搜索查询映射到通用Criteria模型。 搜索格式不必与上面列出的相同。
- 允许我将Criteria模型映射到我需要使用的任何技术 。
- 为Hibernate / JPA / SQL提供映射支持，但这是一个奖励;）
亲切的问候，
格伦
每当我遇到这些问题时，我会问自己“如果我正在创建传统网页，我将如何向用户展示”？ 简单的答案是我不会在一个页面中提供这些选项。 界面太复杂了; 但我能做的是提供一个界面，允许用户在许多页面上构建越来越复杂的查询，这是我认为你应该在这种情况下应该采用的解决方案。
HATEOAS约束指定我们必须在响应中包含超媒体控件（链接和表单）。 所以，假设我们在/cars有一个带有搜索选项的汽车的分页集合，这样当你得到/cars它会返回类似的东西（BTW我在这里使用自定义媒体类型，但表格和链接应该很漂亮显而易见。如果不是，请告诉我）：
... ... ... ... ...
所以，只要说我们搜索白色汽车，我们会GET /cars?color=white ，我们可能会得到类似的东西：
... ... ...
然后，这个结果让我们改进我们的查询。 所以只是说我们想要白色车而不是“灰白色”车，我们可以GET’/ cars？color = white＆color2 = off-white＆color2-logic = not’，这可能会返回
... ... ...
然后我们可以进一步细化我们的查询，但重点是在整个过程中的每一步，超媒体控件告诉我们什么是可能的。
现在，如果我们考虑汽车的搜索选项，颜色，门，品牌和模型都不是无限制的，所以我们可以通过提供枚举来使选项更加明确。 例如
...
然而我们唯一的白色车可能是2门和4门，在这种情况下GETing /cars?color=white可能会给我们带来帮助
...
同样，当我们改进颜色时，我们可能会发现它们只有几个选项，在这种情况下我们可以从提供字符串搜索切换到提供枚举搜索。 例如，GETing /cars?color=white可能会给我们
... ...
您可以对其他搜索类别执行相同操作。 例如，最初您不想枚举所有品牌，因此您将提供某种文本搜索。 一旦集合被细化，并且只有几个模型可供选择，那么提供枚举是有意义的。 同样的逻辑适用于其他集合。 例如，你不想列举世界上所有的城市，但是一旦你将这个区域精炼到10个左右的城市，那么枚举它们会非常有帮助。
有没有一个图书馆会为你做这个？ 没有我知道的。 我见过的大多数人甚至不支持超媒体控件（即你必须自己添加链接和表单 ）。 你有可以使用的模式吗？ 是的，我相信以上是解决此类问题的有效模式。
嗯……这是一个棘手的领域。 没有针对您的问题量身定制的框架。 甚至@ p0wl提到的ODATA对字段映射到域模型的方式也有一定的限制。 一点之后变得奇怪。
解决此问题的最简单方法是将查询作为String接受，然后使用AST或您想要的任何内容对域特定语言进行validation。 这使您可以在接受查询时保持灵活性，同时仍然可以validation查询的正确性。 您失去的是能够通过URL以更有意义的方式描述查询。
看看Restful食谱食谱的第8章 。 它突出了我提出的解决方案之一，并建议采用其他方法。 根据客户所需的灵活性与查询的表现力选择一个。 你可以在某个地方找到平衡点。
@GlennV
我不确定是否存在与此直接相关的模式/规则，如果这是一个常见问题（我的意思是查询字符串中的逻辑运算符），但在设计类似这样的事情时我会问自己以下问题：
- 客户如何构建此类查询？
问题是URI（作为一个整体，包括查询字符串部分）必须完全由服务提供者控制，并且客户端不能直接耦合到特定于您的问题域的URI构造逻辑。
客户端使用URI以及构造它们的方式有多种：
- 客户端可以跟随链接，这些链接通过“链接：<...>”标题或实体主体（如primefaces或HTML链接或类似内容）包含在HTTP标头中
- 客户端可以按媒体类型或其他规范定义的规则构造URI。
引导URI构建过程的几种众所周知的方法：
- HTML GET表单，表单字段根据RFC3986编码，并附加到表单的操作属性值（媒体类型引导）中提供的URI;
- URI模板（相当广泛但值得一读，规范提供了非常有趣的function） RFC6570
- 打开搜索查询（媒体类型引导）
根据上述信息，您可以选择现有方法或设计自己的方法，但要记住简单的规则，服务必须协调客户如何构建查询（即定义您自己的规范，自定义媒体类型或扩展现有）。
另一件事是你如何将URI映射到底层实现，并且在REST方面有两个非常重要的事情：
- 连接器 – 包括HTTP + URI规范，实际上只有连接器对客户端很重要。
- 组件 – 这是底层实现，除了您之外没有人关心。 这部分需要完全隐藏在客户端之外，你可以在这里选择任何绑定方法，没有人能告诉你确切的方法，它完全取决于特定的要求。
你搜索像ODATA（ Link ）这样的图书馆吗？
这将解决您的查询解析问题，您只需将查询转发到您选择的数据库。
如前所述，仍然没有通用的解决方案来做到这一点。 可能最好的选择（至少发现最好的ive）是Spring DATA REST（ http://static.springsource.org/spring-data/rest/docs/1.1.0.M1/reference/htmlsingle/ ）。 使用CrudRepository，您可以获得findOne，findAll等方法。如果扩展它，您可以添加自己的通用映射。 例如，我们所做的是将其扩展为具有通用查询选项，例如：customer？country = notArgentina，以便获得不属于阿根廷的客户。 或者，例如：customer？country = like（ Island ）以获得像“Island”这样的国家/地区的所有客户（以SQL方式）。 希望能帮助到你。