Query APIs: allow empty predicate

[paullatzelsperger]

Query APIs, that take a predicate should be robust enough so that an empty predicate does not cause a 400 error.

Omitting the predicate should be interpreted as "no filter", i.e. return all values, within the limits of limit and offset.

the following circumstances count as "omitted"

• "predicate": ""
• `"predicate": null"
• omitted from JSON

[jimmarino]

Missing, empty, or invalid predicates should throw a client error because the predicate does not correspond to the ANTLR grammar. The 400 error returned is valid because it is invalid input.

If clients want a list all, there is a separate API for that.

[jimmarino]

I've added explicit support for the true keyword in the query grammar. This allows clients to specify the predicate query as {"predicate": "true"} which is explicit, supported directly in the grammar parser, and in line with other predicate grammars.

[fulviocazzanti]

Hi @jimmarino, I've opened PR #54 to address this. I understand your point about the grammar strictness, and the true keyword you added is a good explicit option that the PR preserves.

However, I think treating an omitted/empty predicate as match-all improves the API ergonomics for a few reasons:

1. Principle of least surprise — in most query APIs (SQL, EDC Catalog API, etc.), omitting a filter means "no filter". Returning a 400 for an absent optional parameter feels counterintuitive to API consumers.
2. The predicate field is semantically optional — offset and limit already have sensible defaults (0 and all). If a client just wants paginated results without filtering, requiring them to know about the true keyword adds friction.
3. Backwards-compatible — the true keyword still works exactly as before. This just adds a more lenient path for empty/omitted input, handled as an early return before the ANTLR parser is invoked, so no grammar changes are needed.
4. Separate list-all API — while there is a separate endpoint, query APIs that require a predicate but don't accept "no filter" create an inconsistent experience, especially when clients dynamically build queries and sometimes have no conditions to apply.

The change is minimal: a 3-line early return in ParsePredicate and removing the required tag from the Query model. All existing tests pass and new edge-case tests cover the behavior.

Happy to discuss further or adjust the approach.