On 13-10-15 07:30 PM, Daniel Jenkins wrote:
> 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...
>
This was the initial motivation of moving them into /channels, but that
said, I see it actually being POST /bridges/{bridgeID}/channel and
DELETE. Like you, I agree verbs should not be within the route.
Going to see if I can figure out a better way to DELETE and pass a
parameter.
--
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter:
https://twitter.com/pabelanger
