Plain `field=value` query parameters can only express equality. Compare the common ways a REST API expresses richer filter operators — bracket suffixes like `created_at[gte]=`, right-hand-side prefixes like `created_at=gte:`, and full expression languages such as RSQL/FIQL or OData `$filter` — and say which you'd pick.

## The starting point A query string maps names to values, so `?status=open&owner_id=42` naturally means "status equals open AND owner equals 42". Everything beyond equality-and-AND needs an encoding decision. ## Form 1: bracket suffix operators ``` ?created_at[gte]=2024-01-01&created_at[lt]=2024-02-01&status[in]=open,paid&name[contains]=acme ``` The field is the parameter name, the operator is a bracketed suffix. Stripe, Shopify-era APIs and many Rails/Node stacks use this because their query parsers (`qs`, Rack) already decode `a[b]=c` into a nested map. Advantages: each parameter is a self-contained, independently validatable unit; the field name stays at the front, which makes documentation and whitelisting straightforward; two constraints on the same field compose naturally as a range. Disadvantages: brackets should be percent-encoded (`%5B`/`%5D`) to be strictly correct, though every browser and server tolerates them raw; and it is implicit-AND only — there is no way to say "status open OR total > 1000". ## Form 2: right-hand-side operator prefixes ``` ?created_at=gte:2024-01-01&price=lt:100&status=in:open,paid ``` The parameter name is exactly the field, and the operator rides on the value. Parsing stays flat — no nested-parameter support required, which suits Java/Go/Kotlin stacks whose query parsers are flat maps. The trap is splitting: an ISO-8601 timestamp `2024-01-01T10:00:00Z` contains colons, so you must split on the **first** colon only, and you need a rule for a literal value that itself starts with a known operator prefix (usually: require the prefix form always, or offer an `eq:` escape). Same expressiveness and same implicit-AND limit as brackets. ## Form 3: a real expression language **FIQL/RSQL** — one parameter carrying an infix expression: `filter=created_at=ge=2024-01-01;(status==open,total=gt=1000)` where `;` is AND and `,` is OR. Compact, URL-friendly by design, and there are ready parsers (e.g. rsql-parser in the JVM world) that hand you an AST. **OData `$filter`** — `$filter=created_at ge 2024-01-01 and (status eq 'open' or total gt 1000)`. A full OASIS-standard query language with functions (`contains`, `startswith`), plus `$select`, `$orderby`, `$top`, `$skip`, `$expand`. Huge expressiveness and a real tooling ecosystem; also a large surface to implement, and a spec your team must actually read. **GraphQL-style structured filters in a JSON body** (`POST /orders/search`) is the fourth cousin — worth naming because it is the honest escape hatch when queries exceed URL length or need nesting, at the cost of losing GET caching and clean bookmarkable URLs. ## What actually decides it **Do clients need OR across fields?** If the answer is genuinely no — and for most CRUD-ish APIs it is — the parameter forms win on every other axis: simpler to document, simpler to validate, simpler to translate, and impossible to write a pathological query in. **Cost boundedness.** A parameter form has a fixed maximum shape: N whitelisted fields × M allowed operators. An expression language lets a caller compose an arbitrarily deep predicate; you must then cap expression depth, term count, and the number of non-indexed fields per query, and you should reject rather than silently degrade. Teams that adopt RSQL/OData without those caps discover it when one caller writes a 40-term OR. **Evolvability.** Adding an operator to a parameter form is additive and safe. Adding one to an expression language means grammar and parser changes, and any operator you support is effectively permanent contract. **Consistency.** Whichever you pick, use it identically across every resource. Two grammars in one API is the outcome nobody wants and the most common real-world state. ## The rules that apply to all three Whitelist which fields are filterable and which operators each supports — filtering is a defined capability per field, not a passthrough. Reject unknown fields and unsupported operators with `400` and a machine-readable body naming the offender, never silently ignore them (silent ignoring returns unfiltered data, which in an authorization-adjacent context is a security incident, not a usability wart). Validate and coerce values by field type before they reach the storage layer. Document type-specific semantics — is `name[contains]` case-sensitive? are date bounds inclusive? — because those are the questions that generate support tickets. ## A strong answer "Brackets or RHS prefixes over a whitelisted field×operator matrix, because 90% of real filter needs are AND-of-constraints and those forms stay validatable and cost-bounded. RSQL or OData only when clients need OR and grouping, and then with depth/term caps and a translation layer I control. Whatever I pick, one grammar for the whole API, 400 on anything not whitelisted."