# GET endpoint with potentially thousands of query string parameters

**URL:** <https://discuss.jsonapi.org/t/get-endpoint-with-potentially-thousands-of-query-string-parameters/643>\
**Category:** Uncategorized\
**Created:** [September 12, 2016, 1:21pm UTC](https://discuss.jsonapi.org/t/get-endpoint-with-potentially-thousands-of-query-string-parameters/643 "2016-09-12T13:21:29Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![MarkWalsh](https://avatars.discourse-cdn.com/v4/letter/m/ecae2f/32.png) [@MarkWalsh](https://discuss.jsonapi.org/u/MarkWalsh)\
**Post date:** [September 12, 2016, 1:21pm UTC](https://discuss.jsonapi.org/t/get-endpoint-with-potentially-thousands-of-query-string-parameters/643/1 "2016-09-12T13:21:29Z")

</div>

x-post from my StackOverflow question, I thought I’d ask here as this seems more active than StackOverflow:

Hello there!

I am building some JSON API endpoints which could take potentially thousands of query string parameters. Something which concerns me is the artificial limits set per browser, highlighted in this answer

> <https://stackoverflow.com/questions/812925/what-is-the-maximum-possible-length-of-a-query-string/812962#812962>

I know I could convert my GET endpoints to POST endpoints, but this is breaking the JSON API specification as far as I can tell. Has anyone else had to work around this restriction?

---

<div class="post-metadata">

**Author:** ![jlangley](https://avatars.discourse-cdn.com/v4/letter/j/9e8a1a/32.png) [@jlangley](https://discuss.jsonapi.org/u/jlangley)\
**Post date:** [September 12, 2016, 9:03pm UTC](https://discuss.jsonapi.org/t/get-endpoint-with-potentially-thousands-of-query-string-parameters/643/2 "2016-09-12T21:03:03Z")

</div>

> [@MarkWalsh](#):
>
> this is breaking the JSON API specification

That depends on how you do it.  
Just POSTing to `/resources?filter[a]=1&filter[b]=5...` to retrieve the data is arguably non-compliant.  
But there’s nothing stopping you from creating a “filtered resources” representation: i.e. POST to `/filteredResources` with params in the body to create a new resource representation that is a subset of `/resources`. You lose a lot of caching benefits, but that might not matter depending on what you’re doing.
