RESTful 过滤和查询中的布尔逻辑 [英] Boolean logic in RESTful filtering and queries

问题描述

这是对其他人提出的关于过滤/查询汽车列表的问题的跟进.对 RESTful 过滤请求的建议是将过滤器表达式放在 URI 的查询中，如下所示:

This is sort of a follow-up to someone else's question about filtering/querying a list of cars. There the recommendation for a RESTful filtering request was to put filter expressions in the query of the URI, like this:

/cars?color=blue&type=sedan&doors=4

没关系.但是如果我的过滤查询变得更加复杂并且我需要使用布尔运算符怎么办，例如:

That's fine. But what if my filtering query becomes more complicated and I need to use Boolean operators, such as:

((color=blue OR type=sedan) AND doors=4) OR color=red

也就是说，我想找一辆四门蓝色的车或一辆四门轿车，但如果这辆车是红色的，我就拿它而不关心任何其他属性.

That is, I want to find a four-door blue car or a four-door sedan, but if the car is red I'll take it without caring about any of the other properties.

是否有在 RESTful URI 的查询参数中提供布尔表达式的任何约定?我想我可以通过创建一些新的查询表达式语言并将其放在 POST 中，但这似乎是一种沉重且专有的方法.其他人是如何解决这个问题的?

Is there any sort of convention for providing Boolean expressions in a RESTful URI's query parameters? I suppose I could by create some new querying expression language and put it in a POST, but that seems like a heavy and proprietary approach. How are others solving this?

推荐答案

使用完全没问题

/cars/color:blue/type:sedan/doors:4

代替

/cars?color=blue&type=sedan&doors=4

URL 标准只说路径应该包含层次结构部分，查询应该包含非层次结构部分.由于这是一个 map-reduce，所以使用/是完全有效的.

The URL standard says only that the path should contain the hierarchical part, and the query should contain the non-hierarchical. Since this is a map-reduce, using / is perfectly valid.

在您的情况下，您需要一种查询语言来描述您的过滤器.如果我是你，我会复制现有的解决方案，例如具有 REST API 的 noSQL 数据库的查询语言.

In your case you need a query language to describe your filters. If I were you I would copy an already existing solution, for example the query language of a noSQL database which has a REST API.

• 我认为资源查询语言正是您所需要的.我想你可以这样使用它:

• I think resource query language is what you need. I think you could use it like this:

/sthg?q="(foo=3|foo=bar)&price=lt=10"

或者忘记默认的 queryString 解析器，像这样:

or forget the default queryString parser, and like this:

/sthg?(foo=3|foo=bar)&price=lt=10

我建议您阅读手册以获取更多详细信息.

I suggest you to read the manual for further details.

由于我还没有发现其他与 URL 兼容的查询语言(目前)，我认为唯一可以序列化另一种查询语言并将其发送到参数中的其他选项，例如 SparSQL

Since I found no other URL compatible query language (yet), I think the only other option to serialize another query language and send it in a param, like SparSQL

http://localhost:8003/v1/graphs/sparql?query=your-urlencoded-query

由 marklogic7 提供.Hydra 在其词汇中定义了一个 freeTextQuery，因此它们遵循相同的方法.但我会问马库斯这个.这是一个复杂的主题，因为根据自描述消息约束，您应该在某个地方描述您在 URL 中使用的查询语言类型.我不确定这一点.:S

by marklogic7. Hydra defines a freeTextQuery in its vocab, so they follow the same approach. But I'll ask Markus about this. It's a complicated topic, since according to the self-descriptive messages constraint you should describe somewhere what type of query language you use in the URL. I am not sure about this. :S

结论:

为了支持即席搜索查询，我们需要一种标准方式来在链接元数据中描述它们.目前关于这方面的标准很少.使用最广泛的标准是 URI 模板，它不支持嵌套语句、运算符等...据我所知.有一个名为 link descriptions 的草案试图填补空白，但它是不完整的.

In order to support ad-hoc search queries we need a standard way to describe them in the link meta-data. Currently there are only a few standards about this. The most widely used standard is URI templates which does not support nested statements, operators, etc... for what I know. There is a draft called link descriptions which tries to fill the gap, but it is incomplete.

一种可能的解决方法是使用单个 q 参数定义 URI 模板，该参数具有 x:SearchQuery 的 rdf:type 和 xsd:string 的 rdfs:range，并创建另一个关于如何描述此类 x:SearchQuery 的词汇.之后，描述可用于构建搜索表单，并验证发送到服务器的查询.这种方法也可以支持现有的查询，因此我们不需要新的查询.

One possible workaround to define an URI template with a single q parameter which has rdf:type of x:SearchQuery and rdfs:range of xsd:string, and create another vocab about how to describe such a x:SearchQuery. After that the description could be used to build search forms, and validate queries sent to the server. Already existing queries could be supported too with this approach, so we don't need a new one.

所以这个问题可以通过词汇或新的 URI 模板标准来解决.

So this problem can be solved with vocabs or new URI template standards.

这篇关于RESTful 过滤和查询中的布尔逻辑的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！