Repository navigation
feat: add HTTP method override option #3910
Description
Describe the feature you'd like to request
Make it possible to handle biiiiig input payloads on queries by allowing queries to be sent through HTTP POST.
Describe the solution you'd like to see
allowOverride: booleanon HTTP adapters- With this option enabled, we can ignore the checks that make sure that queries are called with GET and mutations as POST
- A custom link that allows you to remap all queries on the upstream as a
POSTor allowhttpBatchLinkto have some option for it
Describe alternate solutions
Additional information
No response
👨👧👦 Contributing
- 🙋♂️ Yes, I'd be down to file a PR implementing this feature!
Reacted by Roman Zhuravlov, Julien Scholz, craig-pyrra, Konstantin Ryzhov, SamuelBarnholdt, Andrei Karushev, Sun, Victor Glindås and Ketill Antoníus Ágústsson
Activity
[-]feat: add method override option[/-][+]feat: add HTTP method override option[/+]Nick-Lucas commentedon Mar 3, 2023
I agree this needs solving, it was next on my mental list to have a look at based on the number of help topics I've seen with size issues.
Is there a reason that GET is necessary at all? Would it be a problem if all invocations were changed to POST with a body rather than adding more configurability?
Some thoughts of my own:
juliusmarminge commentedon Mar 3, 2023
We have tRPC OpenAPI that lets you expose your trpc router as a rest api though
Nick-Lucas commentedon Mar 3, 2023
Good point, I haven't used it though. I take then it doesn't proxy tRPC with restful methods, it just generates the schema with GET and POST in?
KATT commentedon Mar 4, 2023
HTTP-level caching is nice to be able to have
dtinth commentedon Apr 12, 2023
Some prior art in Ruby world:
Rack::MethodOverrideallows specifying the method via a special parameter_method.It may be possible to allows sending
GETrequests asPOSTby applying the same concept, something like:KATT commentedon Apr 12, 2023
Yup,
_methodis what I'm thinking too[-]feat: add HTTP method override option[/-][+][TRP-58] feat: add HTTP method override option[/+][-][TRP-58] feat: add HTTP method override option[/-][+]feat: add HTTP method override option[/+]AlonMiz commentedon Oct 26, 2023
Totally agree, I find myself trying to read the URL sometimes and my head explodes. it would be super useful to allow ALL params being passed in the request body.
eg. search with useInfiniteQuery, passing many complex filters (dates, numbers, strings) and params, hard to tell between queries, hard to tell what's been sent to the server.
in general, whenever I'm implementing search in a regular app, I would choose
POST /items/searchso I can pass params freely without fearing of encoding and the body is human-readable and predictable.
KATT commentedon Nov 24, 2023
Added a failing test suite in #5099 if someone wants to pick it up
VictorGlindasPaf commentedon Jan 18, 2024
This would be fantastic. We have the requirement that we are not allowed to send values as query parameters, as each request gets logged and may contain sensitive information in the URL.
So I've currently added a TRPC patch to always use POST for queries, but having it built in would be super.
KATT commentedon Feb 29, 2024
This feature has been added in the
next-branch of tRPC, meaning it is available in v11 of tRPC.It's possible to start using it today, have a look at the migration guide for more info: https://trpc.io/docs/migrate-from-v10-to-v11
github-actions commentedon Mar 1, 2024
This issue has been locked because we are very unlikely to see comments on closed issues. If you are running into a similar issue, please create a new issue. Thank you.