REST: Filtering of items (e.g. issues)

The REST API currently allows searching via where_XXX parameters, where
the XXX is a field name. Unfortunately it allows only searching for
classes with a key-property where we can do a lookup, so 
- We currently can't search for strings like "title"
- We can't search for multilinks that do not have a key-property, like
  superseder
- The XXX after the where must be a valid class name, so it works only
  on properties where the class name is the same as the property name,
  e.g. "status" but not "nosy" (status is a Link to the status class,
  nosy is a Multilink to the user class).
- The implementation currently doesn't check for search permissions
- specifying a wrong status only returns the message "An error occurred.
  Please check the server log for more information." not the original
  KeyError 'No key (name) value "something" for "status"'
To sum up, the feature is currently broken.

I'd like to remove the where_ string and use the names of the properties
directly, e.g.

.../data/issue?status=open&nosy=schlatterbeck

To find all issues where I'm on nosy and that are in status open.
That would mean that the pagination feature John implemented which is
currently using page_size= and page_index= parameters would have to be
renamed (we don't want name collisions). John has suggested using an
initial '@' for meta parameters, so this would become @page_size= and
@page_index= similar to roundups current use of special parameters in
the web interface.

Now I'd like to fix the current implementation but have some questions:
- We also want to be able to search for other things, not just
  Link/Multilink properties. This brings up the question of how to
  encode date searches. Probably in the same format that is used by the
  roundup filter call, e.g. 2018-01-01;2019-01-01
- When specifying a string argument to search the user of a REST API
  expects an exact match. Roundups filter implementation currently only
  does case-insensitive substring search. Note that I'm not worried
  changing the filter implementation to add exact string search (keeping
  backward compatibility of course) but more with the REST-API syntax.
- Roundups filter implementation can't currently search for number
  ranges, I'd probably leave this for later

Concerning the string search: We could extend the filter API to allow
exact string matches. That leaves open the question if we want to be
able to expose the current behavior, too (searching for substrings) and
how to syntactically express this in the REST parameters.

If we implement the substring search now as in roundups filter call I
fear we will be stuck with that behaviour for all times. On the other
hand searching for substrings would be a nice feature.

Maybe non-substring search (exact match) could be indicated by an
initial '=', e.g.

/data/issue?title==This is a test

would search for issues where the title is exactly as given. This
however would preclude searching for substrings with an embedded '=' at
the start.

Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   http://www.runtux.com
Reichergasse 131, A-3411 Weidling       email: [email protected]