[asterisk-dev] ARI Text messaging : inconsistencies in the API ?

[Kevin Harwell]

On Wed, Feb 26, 2020 at 1:12 AM Jean Aunis <jean.aunis at prescom.fr> wrote:

> Le 25/02/2020 à 19:09, Kevin Harwell a écrit :
>
> <snip>
>
>
> I could never get (2). When trying to send variables in the
> TextMessageReceived event I would get a validation error unless they are
> formatted like (3).
>
> (3) is the currently declared documented way to to it. As such any other
> way breaks the API definition. However, when executing a sendMessage (1) is
> the way it is currently working, so I'd be worried about breaking current
> implementations if we altered it to (3) for that case.
>
> So what to do?
>
> Option A: Leave sendMessage as is (1), update the documentation for it,
> and fix TextMessageReceived to send variables as defined like (3). Least
> breaking, but inconsistent way of sending and receiving variables.
>
> Option B: Update sendMessage to pass a TextMessageVariable like (3), and
> fix TextMessageReceived to send variables like (3). The current API
> definition doesn't change, but may break implementations.
>
> Option C: Leave sendMessage as is (1), update the TextMessageVariable API
> definition to be similar to (1), e.g { "var name": "var value" }, and not {
> "key": "var name", "value": "var value" }. This of course breaks the
> current API definition, and would break implementations if the validation
> error did not occur.
>
> While "A" is the safest (least breaking?), personally, I prefer and choose
> "C". While it does break the API it seemingly has not worked since the
> start so I don't think this will break any current implementations. It will
> also make sending and receiving variables more consistent.
>
> Thoughts?
>
> I agree with option "C".
>

Went ahead and went with option "C" [1].

[1] https://gerrit.asterisk.org/c/asterisk/+/13843

-- 
Kevin Harwell
Software Developer
Sangoma Technologies
Check us out at: https://sangoma.com & https://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20200228/82789ce7/attachment.html>