# Filtering with potentially large query specifications **URL:** \ **Category:** Uncategorized\ **Created:** [December 18, 2019, 11:02pm UTC](https://discuss.jsonapi.org/t/filtering-with-potentially-large-query-specifications/1796 "2019-12-18T23:02:59Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![fdrake](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/fdrake/32/654_2.png) [@fdrake](https://discuss.jsonapi.org/u/fdrake)\ **Post date:** [December 18, 2019, 11:02pm UTC](https://discuss.jsonapi.org/t/filtering-with-potentially-large-query-specifications/1796/1 "2019-12-18T23:02:59Z")
The specification requires the `filter` query parameter to be reserved for filtering, and states that implementations SHOULD use this. Discussions here suggest that many developers interpret this to include `filter[...]` query parameters in building up complex queries. Others suggest query languages encoded into `filter` (e.g., [Share/Propose a Filtering Strategy](https://discuss.jsonapi.org/t/share-propose-a-filtering-strategy/257)). Has anyone dealt with issues related to very large queries that cannot be encoded into a query string? Many browsers limit the total length of the URL path + query string to around 2K. What I don’t see in the specification is a way to provide very large payloads to define a query. GraphQL has been mentioned, but has the unfortunate trait that using a GET with a content entity is perhaps less well defined and supported than including a larger payload in a POST request. I’d appreciate hearing from developers who are (or have) implemented solutions for queries that become larger than is appropriate for query strings. ---
**Author:** ![fdrake](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.jsonapi.org/fdrake/32/654_2.png) [@fdrake](https://discuss.jsonapi.org/u/fdrake)\ **Post date:** [February 11, 2020, 10:40pm UTC](https://discuss.jsonapi.org/t/filtering-with-potentially-large-query-specifications/1796/2 "2020-02-11T22:40:58Z")
No one has any thoughts on this?