如何设计RESTful高级搜索/过滤器

Question

首先,我已经阅读了用于搜索的RESTful URL设计以及如何设计RESTful搜索/过滤？的问题.我正在尝试设计更高级的选项,以简单和RESTful方式进行搜索.这些问题的答案给了我一些见解和线索,告诉我如何为搜索/过滤功能设计我以前的应用程序网址模式.

首先,我使用模式为基本过滤选项提出了非常好的简单解决方案:

Equality search: key = val

IN search: key = val1 & key = val2

但随着应用程序的增长,搜索要求也在增长.我最终得到了一些相当不愉快和复杂的网址模式,用于高级搜索选项,其中包括:

Negation search: key-N = val

Like search: key-L = val

OR search: key1-O = val1 & key2 = val2

Range search: key1-RS = val1 & key1-RE = val2

更重要的是,除了过滤器,查询必须获取有关分页和顺序的信息,因此过滤器参数具有F-后缀,按字段排序具有O-后缀,并且分页具有P-后缀.

我希望在这一点上我不必补充说解析这样的请求是相当恶意的任务,如果密钥包含' - '则可能存在歧义.我创建了一些正则表达式来解析它,它现在运行得很好,但......

现在我开始编写一个新的Web应用程序,我有机会从头开始重新设计这个部分.

我想知道在包含所有信息的浏览器中以结构化和不言自明的方式创建对象,并将其作为JSON字符串发送到服务器,如:

filter = {{'type':'like','field':key,'value':val1,'operator':'and','negation':false},..}

但我感到奇怪的是,这不是一个好主意 - 我真的不知道为什么.

所以,这将是我的上下文的定义.现在的问题是:

我正在寻找更简单,更安全的模式来实现高级搜索,包括我上面提到的RESTful GET参数选项 - 你能分享一些想法吗？或者也许是一些关于不以RESTful方式执行此操作的见解？此外,如果你看到JSON方式的一些陷阱,请分享它们.

编辑:

我知道是什么让json成为get参数,不是那么好主意.对它进行编码 - 它使它难看且难以阅读.

由thierry templier发出的链接提供的信息给了我一些思考的东西,我设法在GET参数中设计了更多的有条理和安全的过滤器处理.下面是语法的定义.

对于过滤器 - 多个F参数(每个搜索标准一个):

F = OPERATOR:NEGATION:TYPE:FIELD:VAL[:VAL1,:VAL2...]

允许值:

[AND|OR]:[T|F]:[EQ|LI|IN|RA]:FIELD_NAME:VALUE1:VALUE2...

对于order by - 多个O参数(每个有序字段一个):

O = ODINAL_NO:DIRECTION:FIELD

允许值:

[0-9]+:[ASC|DESC]:FIELD_NAME

分页 - 单P参数:

P = ITEMS_PER_PAGE:FROM_PAGE:TO_PAGE

我认为这将是一个很好的解决方案 - 它满足我的所有要求,它易于解析和编写,它是可读的,我不知道该语法如何变得模棱两可.

我对这个想法的任何想法都很感激 - 你看到任何陷阱吗？

Answer 1

这里有几种选择.但很明显,如果你的查询往往与运算符一样复杂,等等......你就不能使用一组查询参数.我看到两种方法:

我认为您可以查看ElasticSearch的查询内容.他们能够使用JSON内容(使用多个级别)描述非常复杂的查询.以下是他们的查询DSL的链接:http://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html.

您还可以查看OData为查询所做的工作.他们选择具有单个查询参数的另一种方法$filter.以下是一些可以提供一些示例的链接:https://msdn.microsoft.com/en-us/library/hh169248(v = nav.70)和http://www.odata.org/documentation/odata- version-3-0/url-conventions /.此选项要求在服务器端具有语法来解析查询.

一般而言,此链接还可以在"过滤数据"部分中为您提供此级别的一些提示:https://templth.wordpress.com/2014/12/15/designing-a-web-api/.

希望它能为您提供一些在RESTful服务中设计查询的有用提示;-)

蒂埃里