如何设计RESTful进阶search/filter
How to desing RESTful advanced search/filter
首先,我阅读了RESTful URL design for search and How to design RESTful search/filtering?题。我正在尝试设计更高级的选项,以便以简单且 RESTful 的方式进行搜索。
这些问题的答案为我提供了一些关于如何为 search/filter 功能设计我以前的应用程序 url 模式的见解和线索。
首先,我想出了一个非常简单的基本过滤选项解决方案,使用模式:
Equality search: key = val
IN search: key = val1 & key = val2
但是随着应用程序的增长,搜索需求也在增长。我最终得到了一些相当令人不快且复杂的 url 高级搜索选项模式,其中包括:
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
此外,query除了filters,还需要获取pagination和order by的信息,所以filter参数后缀为F-,order by fields后缀为O-,pagination参数后缀为P-
我希望此时我不必补充说解析此类请求是相当恶意的任务,如果密钥包含“-”,则可能会产生歧义。我已经创建了一些正则表达式来解析它,目前它运行良好,但是...
现在我开始编写一个新的网络应用程序,我有机会从头开始重新设计这一部分。
我想知道如何在浏览器中以结构化和不言自明的方式创建包含所有信息的对象,并将其作为 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...
对于排序依据 - 多个 O 参数(每个排序字段一个):
O = ODINAL_NO:DIRECTION:FIELD
允许的值:
[0-9]+:[ASC|DESC]:FIELD_NAME
分页-单P参数:
P = ITEMS_PER_PAGE:FROM_PAGE:TO_PAGE
我认为这将是一个很好的解决方案 - 它满足我的所有要求,易于解析和编写,可读性强,而且我不认为语法会变得模棱两可。
我很感激任何关于这个想法的想法 - 你看到任何陷阱吗?
这里有几个选项。但很明显,如果您的查询往往因运算符等而变得复杂,那么……您不能使用一组查询参数。我看到两种方法:
- 将查询作为 JSON 内容提供给方法
POST
- 在具有特定格式/语法的查询参数中向方法提供查询
GET
我想你可以看看他们的查询用什么 ElasticSearch。他们能够用 JSON 内容(使用多个级别)描述非常复杂的查询。这是他们查询 DSL 的 link:http://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html.
您还可以查看 OData 对查询的作用。他们选择了另一种使用单个查询参数 $filter
的方法。这里有一些 link 可以给你一些例子:https://msdn.microsoft.com/en-us/library/hh169248(v=nav.70) and http://www.odata.org/documentation/odata-version-3-0/url-conventions/。此选项需要在服务器端有语法来解析您的查询。
一般来说,这个 link 也可以在其 "Filtering data" 部分给你这个级别的一些提示:https://templth.wordpress.com/2014/12/15/designing-a-web-api/。
希望它能给您一些有用的提示,帮助您在 RESTful 服务中设计查询 ;-)
蒂埃里
首先,我阅读了RESTful URL design for search and How to design RESTful search/filtering?题。我正在尝试设计更高级的选项,以便以简单且 RESTful 的方式进行搜索。 这些问题的答案为我提供了一些关于如何为 search/filter 功能设计我以前的应用程序 url 模式的见解和线索。
首先,我想出了一个非常简单的基本过滤选项解决方案,使用模式:
Equality search: key = val
IN search: key = val1 & key = val2
但是随着应用程序的增长,搜索需求也在增长。我最终得到了一些相当令人不快且复杂的 url 高级搜索选项模式,其中包括:
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
此外,query除了filters,还需要获取pagination和order by的信息,所以filter参数后缀为F-,order by fields后缀为O-,pagination参数后缀为P-
我希望此时我不必补充说解析此类请求是相当恶意的任务,如果密钥包含“-”,则可能会产生歧义。我已经创建了一些正则表达式来解析它,目前它运行良好,但是...
现在我开始编写一个新的网络应用程序,我有机会从头开始重新设计这一部分。
我想知道如何在浏览器中以结构化和不言自明的方式创建包含所有信息的对象,并将其作为 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...
对于排序依据 - 多个 O 参数(每个排序字段一个):
O = ODINAL_NO:DIRECTION:FIELD
允许的值:
[0-9]+:[ASC|DESC]:FIELD_NAME
分页-单P参数:
P = ITEMS_PER_PAGE:FROM_PAGE:TO_PAGE
我认为这将是一个很好的解决方案 - 它满足我的所有要求,易于解析和编写,可读性强,而且我不认为语法会变得模棱两可。
我很感激任何关于这个想法的想法 - 你看到任何陷阱吗?
这里有几个选项。但很明显,如果您的查询往往因运算符等而变得复杂,那么……您不能使用一组查询参数。我看到两种方法:
- 将查询作为 JSON 内容提供给方法
POST
- 在具有特定格式/语法的查询参数中向方法提供查询
GET
我想你可以看看他们的查询用什么 ElasticSearch。他们能够用 JSON 内容(使用多个级别)描述非常复杂的查询。这是他们查询 DSL 的 link:http://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html.
您还可以查看 OData 对查询的作用。他们选择了另一种使用单个查询参数 $filter
的方法。这里有一些 link 可以给你一些例子:https://msdn.microsoft.com/en-us/library/hh169248(v=nav.70) and http://www.odata.org/documentation/odata-version-3-0/url-conventions/。此选项需要在服务器端有语法来解析您的查询。
一般来说,这个 link 也可以在其 "Filtering data" 部分给你这个级别的一些提示:https://templth.wordpress.com/2014/12/15/designing-a-web-api/。
希望它能给您一些有用的提示,帮助您在 RESTful 服务中设计查询 ;-)
蒂埃里