Feature request: Allow for header arguments to be passed in query too

[SmallhillCZ]

Problem:
When using software that doesn't allow to specify HTTP headers (stata, excel, etc.), users can't get data from PostgREST.

Solution:
Allow passing these arguments also as query parameters.

Authorization: Bearer <token> could be also passwed as ?token=<token>, similarily with Accept: <format> as ?format=<format>

[steve-chavez]

This is also a problem for embedded devices(like SIM modules) that only support GET/POST methods. For this case perhaps a __method parameter could be supported.

This is all part of the same problem(clients with incomplete HTTP support) so these special parameters could be enabled through a config option.

[wolfgangwalther]

I think those cases are so special, that I wouldn't put them into postgrest itself.

What about creating some nginx configuration examples for how to do stuff like this on the reverse proxy level?

People could then customize what kind of headers their clients support and add the respective things to their URL parsing.

[steve-chavez]

I think those cases are so special, that I wouldn't put them into postgrest itself.

There are lots of Arduino use cases out there that we currently don't support. Putting a tutorial like "you need Nginx plus custom config to make this work" is no good.

Additionally there's GIS software that can't use headers as mentioned on PostgREST/postgrest#223 (comment). And there are lot of great things we can do on the GIS space too(as I put on this example).

[wolfgangwalther]

There are lots of Arduino use cases out there that we currently don't support. Putting a tutorial like "you need Nginx plus custom config to make this work" is no good.

A tutorial like this would be a great thing.

I understand that there are a lot of deficient clients. But each of those clients has their own deficiencies. I don't think we should try to support them all. Instead we should focus on doing one thing well - and that's exposing a RESTful api.

Reverse proxies are made for those kind of things. If we put up a configuration example for nginx that includes all those __method, __token, __format and whatever parameters, a user can simplify it by taking the parts out they don't need. And they can easily extend it for their own use-case. If we instead put it into PostgREST we will have all kind of feature requests down the road, requesting new fallback parameters...

[steve-chavez]

Instead we should focus on doing one thing well - and that's exposing a RESTful api.

PostgREST/postgrest#1735 could have been done by a proxy too yet we still added it, this is a similar use case.

That being said, since we have other pressing issues this can be done as a how-to("Supporting clients with incomplete HTTP support") for now. So moving it to docs.