首先,我已阅读RESTful URL design for search和How to design RESTful search/filtering?个问题。我正在尝试设计更高级的选项,以简单和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-后缀。
我希望在这一点上我不必添加解析这样的请求是相当恶意的任务,如果密钥包含' - '则可能存在歧义。我创建了一些正则表达式来解析它,它现在运行得很好,但是......
现在我开始编写一个新的网络应用程序,我有机会从头开始重新设计这个部分。
我想知道在包含所有信息的浏览器中以结构化和不言自明的方式创建对象,并将其作为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
我认为这将是一个很好的解决方案 - 它满足我的所有要求,它易于解析和编写,它是可读的,我不知道该语法如何变得模棱两可。
我很欣赏任何关于这个想法的想法 - 你看到任何陷阱吗?
答案 0 :(得分:5)
这里有几种选择。但很明显,如果您的查询往往与运营商一样复杂,等等......您无法使用一组查询参数。我看到两种方法:
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/。此选项要求在服务器端使用语法来解析查询。
一般情况下,此链接还可以在其“#34;过滤数据":https://templth.wordpress.com/2014/12/15/designing-a-web-api/”部分中为此级别提供一些提示。
希望它能为您提供一些在RESTful服务中设计查询的有用提示; - )
亨利