api - How to desing RESTful advanced search/filter -

First of all, I have read and tried to find out more advanced options for searching in a simple and quiet way. I am answering those questions to give me some insights and clues about how to design my previous app url patterns for search / filter functionality.

First of all, I came up with a nice and simple solution for basic filtering options using patterns:

  similarity search: key = in search Is: key = val1 & amp; Key = val2  

But as the application has increased, there were search requirements. And I ended up with some more unpleasant and complex URL patterns for advanced search options, including:

  incorporation search: key-N = val like search: key-L = val Search: key1-O = Val 1 & amp; Key2 = val2 range search: key1-rs = val1 & amp; Most of the filters will be located next to the filter, information about paging and order, so that the filter parameter has an F-suffix, the order of the field is pro-suffix, and pointing to the page is P-suffix.  
 I hope that at this point I do not have to add that parsing such a request is a malicious act, which has the possibility of ambiguity if the key has '-'. I've made some regexp to parse it, and it works quite well for now, but ...  
 Now I'm starting to write a new web app and I'm going to have this piece Has got a chance to get a new look.  
 I'm thinking of creating an object in a browser that contains all the information in a structured and self-explanatory manner and sending it as a JSON string on the server such as:  
  filter = {{'Type': 'like', 'field': key, 'value': val1, 'operator': 'and', 'negation': false}, ..}  
 
 But I feel strange that this is not a good idea - why do not I really know. 
 
 So, this will be the definition of my reference now: Question: 
 
 I am looking for a simple and secure pattern to implement advanced search in which I am going to give the above mentioned options as a standard GET parameter As mentioned - Can you share some ideas? Or maybe not something like this in a quiet way? Also, if you see some damage in the way of Jason, please share them. 
 
  Edit:  
 
 Good idea. It encoding - it makes it ugly and hard to read. 
 
 The information given by Link to links by Thierry Templeler was given to me a few thoughts and I have been able to create more consistent and secure filter handling in GET parameters. Below is the definition of syntax. 
 
 For Filters - Many F parameters (one for each search value): 
 
  F = operator: Incorporation: type: field: val [VAL1, VAL2. .]  
 
 Permission value: 
 
  [AND | OR]: [T | F]: [EQ | LI | IN | RA]: FIELD_NAME: VALUE1: VALUE2 ...  
 
 Order by - Multiple O parameters (one for each ordered field): 
 
  O = ODINAL_NO : Direction: Field  
 
 Allowed values: 
 
  [0-9] +: [ASC | DESC]: FIELD_NAME  
 
 Pagination - Single P parameter: 
  P = ITEMS_PER_PAGE: FROM_PAGE: TO_PAGE  

< P> I think this would be a good solution - it meets all of me requirements, it is easy to parse and write, it is readable and I do not think how this syntax can be ambiguous.

I appreciate any thoughts on this idea - do you see any damage? There are many options here but it is clear if your questions are complicated with operators, and so on.

... You can not use a set of query parameters. I look at two ways:

• Provide a query as a method
• as JSON content with a specific parameter Provide a query in a query parameter / grammar for a method> get

I think what you see about eListastic Search for your questions You can. They are able to describe very complex questions with JSON content (using multiple levels) here their query is a link to DSL.

You can also look for Odata's questions. They choose another approach with a single question parameter $ filter Here are some links that can give you some examples: and this option requires grammar on the server side to parse your query is.

In general, this link can give you some pointers at this level in your section of "filtering data":.

Hope this gives you some helpful hints for designing your questions within your undoubtedly services; -)

Thierry