All geek questions in one place

Logical logic in filtering and RESTful queries

Below is a description of another question about filtering / querying a list of cars. There, the recommendation for a RESTful filtering request was to put filter expressions in a URI request, for example:

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

It's good. But what if my filtering request becomes more complex, and I need to use logical 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 will take it without worrying about any other properties.

Is there any convention for providing boolean expressions in RESTful URI request parameters? I suppose I could create a new query expression language and put it in POST , but this seems like a tough and proprietary approach. How do others solve this?

+5
source share
3 answers

It is quite normal to use

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

instead

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

The URL standard only states that the path must contain a hierarchical part, and the request must contain a non-hierarchical one. Since this mapping is abbreviation, using / is excellent.

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

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

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

    or forget the default request handler by default and like this:

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

    I suggest you read the manual for more details.

  • Since I have not yet found another URL-compatible query language, I think this is the only other option for serializing another query language and sending it in a parameter, for example SparSQL

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

    marklogic7 . Hydra defines freeTextQuery in its vocab, so they take the same approach. But I will ask Marcus about this. This is a tricky topic, because according to the restriction of self-describing messages, you must specify somewhere what type of query language you use in the URL. I'm not sure about that .: S

Conclusion:

To support special search queries, we need a standard way to describe them in link metadata. Currently, there are only a few standards. The most common standard is URI patterns , which does not support nested operators, operators, etc ... for what I know. There is a project called link descriptions that tries to fill in the gap, but it is incomplete.

One possible workaround is to define a URI template with one q parameter that has rdf: type x: SearchQuery and rdfs: range of the xsd: string string and creating another dictionary on how to describe such an x: SearchQuery. After that, the description can be used to create search forms and verify requests sent to the server. Existing requests can also be supported with this approach, so we do not need a new one.

Thus, this problem can be solved with the help of dictionary characters or the new URI template standards.

+3
source

I saw that many use the query string, as you indicated, as the SQL query string.

Here are just two examples:

+2
source

Try using 1 for true, 0 for false.

 /_api/web/lists/getbytitle('XYZ')/items?$filter=Active eq 1
0
source

Source: https://habr.com/ru/post/1202168/

More articles:


All Articles