commit 6cfbb2995d394695ce790fe805642523eb772105
author Edwin Kempin <ekempin@google.com> Wed Jan 04 09:40:50 2017 +0100
committer Edwin Kempin <ekempin@google.com> Wed Jan 11 11:56:03 2017 +0100
tree fb5a9cb3b1404ecfa57c61a8edea036f3e8d7258
parent d819316d4255ecb8cf061607eba8eedd9854fb78

Support arbitrary group queries via REST

GET /groups/?query2=<query> supports arbitrary group queries now.
The matching groups are returned as list of GroupInfo entities in the
order as they are returned from the index. The 'start' and 'limit'
parameters can be used to skip/limit results. In a follow-up change a
boolean _moreGroups field will be added to the last returned result so
that the client knows whether there are more results which could be
queried (e.g. to implement paging).

While we want to return the query results as list (which is also
consistent with how query results are returned for changes and
accounts) the existing GET /groups/ REST endpoint returns matching
groups as map. This can't be changed since it would break API
compatibility. To work around this we have two seperate REST endpoint
implementations for GET /groups/:

1. ListGroups:
   This is the existing REST endpoint which lists groups and returns
   them as map.
2. QueryGroups:
   New REST endpoint that supports arbitrary group queries and which
   returns the results as list.

Which of these two REST endpoint implementations is invoked on
GET /groups/ is decided by the presence of the 'query2' parameter. If
the 'query2' parameter is specified the QueryGroup REST endpoint is
invoked. If it is missing the request is handled by the List Groups
REST endpoint.

To implement this switch the GroupsCollection REST endpoint must know
about the request parameters. For this GroupCollection implements the
new optional NeedsParams interface so that it gets the request
parameters. It can then check if the 'query2' parameter is present and
then return the corresponding REST endpoint implementation from its
list() method. This way we keep API compatibility for the existing
ListGroups REST endpoint while the new QueryGroups REST endpoint can
return the results as list.

The parameter is named 'query2'/'q2' because 'query'/'q' is already
used in ListGroups.

Having a new REST endpoint for quering groups is also cleaner as
extending the existing ListGroups REST endpoint has many parameters
that are incompatible with querying and it's confusing for users to
understand which parameters can be combined.

The new QueryGroups REST endpoint requires a group index and fails
with '405 Method Not Allowed' if the group index is missing.

The functionality of the existing ListGroups REST endpoint is not
modified and it still doesn't make use of the group index.

Change-Id: I5b916894f62e99bbff82e137fa131b154d80872c
Signed-off-by: Edwin Kempin <ekempin@google.com>