Generic Webhook: JSON array in parameter

[phipolis]

Is it possible to place a JSON array in a generic webhook url parameter?

I know this teeters on madness and encoding arbitrary JSON, but with the new $data=value syntax introduced in #377 it is almost possible to connect shoutrrr to a signal-cli-rest-api instance as discussed in #66 (comment). The minimal JSON payload (swagger ref) is:

{"message":"test","number":"+000000","recipients":["+11111"]}

A shoutrrr url like

generic://host:port/v2/send?template=json&$number=%2b000000&$recipients=["%2b11111"]

Produces

{"message":"test","number":"+000000","recipients":"[\"+11111\"]"}

Which would be perfect except for the quoting / escaping on the recipients parameter.

[piksel]

No all values are strings, so you would never get an actual array in the output. It might work if you use multiple $recipient args, but I have not checked it... Nope, it only uses the first value...

So, yeah, we could add a mechanism to allow you to specify that a field is an array, but it does start to sound like more complexity than I would like to have in a service that is inherently untestable...

[phipolis]

@piksel That is a reasonable concern.

One thought I had for a less invasive solution would be a prefix to disable the auto quoting and escaping, something like $$rawdata=value or ~rawdata=value. However I suspect the bigger issue is knowing the right structure and creating it for the JSON serializer. A special case for just lists might be $rawdata=[value1,...], but it would still take a fair amount of logic to parse.

Another possibility might be making a service specifically for the signal-cli-rest-api that just uses the generic webhook service in JSON mode but wraps the recipients parameter(s) in a list before generating the json string output.

[piksel]

Yeah, adding a new service is probably a better solution. I'll give it a shot the next time I get some spare time!