Is there a way to define optional query parameters?

[on3iro]

Hey,

I would like to have some kind of request template, where I can inject query parameters from the cli via --vars.
Currently ain will complain if a var is empty and will also try to include a query parameter even if it's value is an empty string for example.

Is there an easy way to have a base request where I can optionally define query parameters?
I probably could create an .ain file for each of the parameters and use the respective files in the cli call, but this seems cumbersome and rather complicated to use.

Thanks :)

[jonaslu]

Hi,

Yes, from what I've understood an empty value in a QP is a valid QP, so it will accept that.

Currently there is a hacky way (if your request has at least one query parameter per call). It uses an executable to do logic. Example in bash:

[Query]
$(bash -c 'if [ -n "$VAR" ]; then echo param=$VAR; else echo " "; fi')

You can use any language, as long as it can be invoked to eval a string and can access environment variables. Example in node:

[Query]
$(node -e 'if ( process.env.VAR !== undefined) { console.log("param="+process.env.VAR) } else { console.log(" ") };')

But it doesn't read too nicely, esp. the printing of an empty string to get around an executable needs to have some output. So it might be better to stick all of it in it's own bash, node or whatever script and just call that executable for now.

I've actually been thinking about this case too, since conditionals would be nice and I've run into similar cases as you when it would be better to have conditionals in the actual template instead of in a script by the side.

I'm leaning towards multi-line executables so you can do more logic in any language of your choice and that the executable is allowed to produce no output.

[on3iro]

Thanks for the quick answer. For now I kinda solved the issue (for my current specific scenario) by adding additional more narrowed down .ain files. So I have a default file getSomething and and additional one getSomethingWithFilter.
For my particular use case this is fine, however a more flexible but still nice to read solution would definitely be better.