Using HTTP:POST for `query`?
Hey guys, thanks for the awesome library!
My application involves making a
query with a large amount of JSON data. However, since we use HTTP:GET under-the-hood for queries ( including batching ), I run into header length limits. Since we deploy to AWS, we are also restricted to the length limit imposed by Amazon ALB. Due to this, I have the following questions :
- Is it currently possible to use HTTP:POST for query and mutation?
- If not, is there any appetite to support it?
- It would be easier for batching use-cases ( since the size limits of the batch can be a lot larger by default ), reduced code-complexity over-all, and also be consistent with other RPC implementations that only use POST for all transport.5 Replies
In order to unblock myself, i'm just using react-query to wrap the
useMutation explicitly which i've extracted into an abstract function. However, not having to deal with this issue at-all would be ideal.Using a mutation is the right workaround
It's not a great idea to run useQuery with a lot of input data, and is indicative of a problem with the code at large. Mutations are more suited
There has been talk of supporting custom verbs for queries, but you'd be best to look at github for the outcomes of that
At the end of the day, they are both RPC calls and the input / output shouldn't matter. The only reason there is any difference between whether something is a mutation / query at all seems to be for cleaner integration with react-query.
Rather than allow customising the underlying verb, using
POST for everything would simplify everyone's lives IMO. I don't really see why there's any need for the HTTP verb to change based on whether something is a query or mutation within the app. The transport is mostly abstracted from the user anyway.Caching and GET verbs go together on the web, that's the main reason IIRC 🙂
Hmm, good point. However, caching API responses doesn’t seem like a standard use case. Especially if it’s behind auth as well.
I was also under the impression that as long as cache-control headers are present, POST requests will be cached as well ( by CDNs and the browser )