API: send - special case for single recipients for use with limited senders

[phipolis]

Feature Request

The v2/send endpoint's requirement that recipients be a list of strings is difficult to satisfy when calling through services that offer limited expressiveness for building a JSON object. While this isn't the API's fault, it would occasionally be really helpful if "recipients":"number" were treated as being equivalent to "recipients":["number"], or if there was an alternative "recipient":"number" parameter with the same effect.

I've been struggling with satisfying this endpoint lately in various notifier services:

Here with diun, although I found a workaround;

Here with shoutrrr, which maps url query params into a single level dict of strings, but can't currently express more complex JSON.

[phipolis]

I just realized there's an existing issue, #372, involving Synology's notification service having a similar limitation where the requirement that recipients be in an array prevents interoperability.

The API is designed around rich multimedia chat and these weird clients are of course not the focus. But it would occasionally be handy to be able to send machine-generated alerts to oneself!

[bbernhard]

That's a tough one. On the one hand, I can see that there are certain clients out there which for whatever reason don't support the array syntax. On the other hand, this is probably also the minority. And adding a simplified endpoint probably makes it a bit more confusing for the regular user. But as this is already the second issue in that regard, I can see that there is a need for that. I'll think about it. Are you currently blocked by that or did you find a workaround?

[DigitalTuna]

Hi @bbernhard. In your last post you wanted to think about making recipients a simple string (additionally to being it an array) thus it would be possible to be used with Sinology notifications.
Did you come to any decision?

[bbernhard]

I've just added a recipient parameter to the /v2/send endpoint. As most users are perfectly fine with the recipients array parameter, I've decided to not expose the recipient parameter in the Swagger UI. I hope that compromise is fine for everybody.

[DigitalTuna]

Thanks you very much! Would you push this new version to docker hub, so I can just get the image?

[bbernhard]

Here's a test version: bbernhard/signal-cli-rest-api:0.141-dev