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

Question

首先，我已经阅读了RESTful URL design for search和 How to design RESTful search/filtering?问题。我正在尝试以简单和 RESTful 的方式设计更高级的搜索选项。
这些问题的答案为我提供了一些关于如何为搜索/过滤功能设计我以前的应用程序 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

更重要的是，除了filters，query还要获取分页和order by的信息，所以filter参数有F-后缀，order by字段有O-后缀，pagination有P-后缀。

我希望此时我不必补充解析此类请求是一项相当恶意的任务，如果 key 包含“-”，则可能会产生歧义。我已经创建了一些正则表达式来解析它，它现在工作得很好，但是......

现在我开始编写一个新的网络应用程序，我有机会从头开始重新设计这件作品。

我想知道如何在浏览器中以结构化和不言自明的方式创建包含所有信息的对象，并将其作为 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

这里有几个选项。但很明显，如果您的查询倾向于使用运算符复杂，等等……您不能使用一组查询参数。我看到两种方法:

将查询作为 JSON 内容提供给方法 POST

将查询参数中的查询以特定格式/语法提供给方法 GET

我认为您可以查看一下 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 服务中设计你的查询 ;-)

蒂埃里