Breaking: change filters to compose as OR instead of AND

[bart-degreed]

The current JsonApiDotNetCore documentation states:

Filters can be combined and will be applied using an AND operator. The following are equivalent query forms to get articles whose ordinal values are between 1-100.

GET /api/articles?filter[ordinal]=gt:1,lt:100 HTTP/1.1
GET /api/articles?filter[ordinal]=gt:1&filter[ordinal]=lt:100 HTTP/1.1

This violates the json:api official recommendations, which are using the OR operator in comma-separated parameters.

Multiple filter values can be combined in a comma-separated list. For example:

GET /comments?filter[post]=1,2 HTTP/1.1

While it does not explicitly state that OR must be used, the example only makes sense for an OR operator: get the comments that are attached to post 1 or 2. When AND was intended, it would mean: get the comments that are attached to both post 1 and 2, which makes no sense.

So I propose to change the existing behavior of JsonApiDotNetCore from AND to OR interpretation on comma-separated lists (or passing the same parameter multiple times, which is functionally equivalent):

GET /comments?filter[post]=1,2 HTTP/1.1
GET /comments?filter[post]=1&filter[post]=2 HTTP/1.1

would mean: comment.post must be 1 OR 2.

Note this proposal does not change the behavior of different parameters. So, for example:

GET /people?filter[name]=joe&filter[age]=gt:30 HTTP/1.1

would still require both conditions to match (AND).

[bart-degreed]

In addition to this, we may want to extend the 'in' operator on filters to allow for specifying a range.

GET /api/articles?filter[ordinal]=in:1..100 HTTP/1.1

We may consider to extend syntax to indicate whether the begin and/or end are inclusive/exclusive:

GET /api/articles?filter[ordinal]=in:[1..100> HTTP/1.1

would mean: ordinal must be 1 or higher, up to (but not including) 100.