[Feature Request] Allow GET request with body

[QzCurious]

The data parameter of axios is omitted from get method by ZodiosRequestOptionsByPath.

Note: Sending body/payload in a GET request may cause some existing implementations to reject the request — while not prohibited by the specification, the semantics are undefined. It is better to just avoid sending payloads in GET requests.
MDN

Could zodios be less opinionated about it?

[ecyrbe]

MDN is right.
It's not prohibited per say by HTTP, but the HTTP 1.1 spec also said that if there is a body it can be ignored by anything that handled it as it should not influence the server response.
Now in practice it's not advisable to do so. But don't just keep theorical.

I'll not complexify zodios just for theorical use cases.

If there is real issues and many users examples having no choice but to use GET with body i'll review my position.

Until then, it's not on the roadmap to add body support for body on get requests.

[ecyrbe]

Transferred to discussion

[QzCurious]

Yes, it rare to have body with GET. I'll discuss it with the backend developer of my team. Or it's only one or two endpoint, I can force typescript ignore the error as zodios still passesdata to its underlining axios request.

[ecyrbe]

Yes, even better, if you can tell them to come here explain why they do so.
I need more input and use cases.
Maybe they have a use case that can't be fullfilled with an immutable POST request.
Thanks in advance.

[ivan-kleshnin]

My advice for all novice programmers: don't send HTTP bodies with GET. It may work & look fine for some time, with some tools...
But sooner or later you'll hit the wall. 🧱 It will look like a requirement to use another tool that simply drops GET bodies.
Trust me, we've all been there.

I know you're trying to implement a search in your app.

GET responses are cached. Now some tools (that allow HTTP GET body) will took that body into account. And filters alone can lead to a combinatory explosition of cached variants. You certainly don't want it. Other tools will cache just URL, ignoring body, so you'll end up with invalid request/response substitutions. You don't want it neither.

Given all that, use either GET with query params if you're ok with large cache sizes (if you have narrow set of filter values) or POST with body (JSON) params for search. I'd personally just go with POST /[your-model-name(s)]/search. It's a case where having a verb in "REST" API is perfectly fine.