On Tue, Oct 15, 2013 at 11:38 PM, Matthew Jordan <mjordan at digium.com> wrote:
>
> On Tue, Oct 15, 2013 at 5:14 PM, Paul Belanger <
> paul.belanger at polybeacon.com> wrote:
>
>> On Tue, Oct 15, 2013 at 3:35 PM, David M. Lee <dlee at digium.com> wrote:
>> >
>> > On Oct 15, 2013, at 12:24 PM, Paul Belanger <
>> paul.belanger at polybeacon.com> wrote:
>> >
>> >> On Tue, Oct 15, 2013 at 1:07 PM, Joshua Colp <jcolp at digium.com> wrote:
>> >>> Paul Belanger wrote:
>>
>
> <snip>
>
>
>>
>> > And you would have to pass the bridgeId into the DELETE, and passing
>> > params into deletes is just freaky.
>> >
>> Ya, this is still an issue I guess. Can a channel live within more
>> then one bridge? I don't think it can right? So, if DELETE
>> /channels/{channelId}/bridge asterisk would have to look for said
>> channel. Not sure that is the right approach either.
>>
>>
> Nope. Having a channel exist in multiple bridges would have been cool, but
> would have required another year of development (if not more).
>
> There's two reasons why a channel joining a bridge should be an operation
> on a bridge, and not a channel:
> (1) The first is what you just pointed out: a channel can only be in one
> bridge, but a bridge can have many channels. Thus calling addChannel on
> multiple channels is acceptable; calling bridge on a channel multiple times
> is not.
> (2) Following that, from an OO perspective (which we have going with our
> resources and their properties/relationships), what changes is the bridge,
> not the channel. The bridge assumes ownership of the channel; hence it
> should be operations on the bridge that take ownership and release it.
> (2) A bridge is not a state that a channel is in, which
> /channels/{id}/bridge implies. A bridge is an object. It has its own
> lifetime, properties, and state. Saying "bridge some channels" is actually
> a misnomer now: channels are in a bridge, they may have a bridge supporting
> them, but the bridge itself is a thing and the channels are just along for
> the ride.
>
> I know that's a pretty sharp departure from previous versions of Asterisk,
> and goes against the grain of how we think about calls and channels and
> bridging: but I think it's important that we reflect that, particularly as
> we flesh out more complicated bridge technologies.
>
> --
> Matthew Jordan
> Digium, Inc. | Engineering Manager
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: http://digium.com & http://asterisk.org
>
> _______________________________________________
> asterisk-app-dev mailing list
> asterisk-app-dev at lists.digium.com
> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
>
>
I've just realised, that routes in the ARI contain verbs... like "add" in
"addChannel"
I know Mr Lee said that he didn't go full on HATEAOS style, but your verbs
are meant to be your GET, POST, PUT and DELETE methods and so the fact
you're doing a post means create and the fact you're doing PUT means you're
adding...
Is this a rabbit hole we want to go down? I just don't like routes that
contain verbs, it feels messy to me.
But again, it's whatever is right for the particular API, and I may be
talking absolute BS when it comes to how it relates to Asterisk...
Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131016/fffe5256/attachment.html>
