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:
>>>> POST /bridges/{bridgeId}/addChannel
>>>> POST /bridges/{bridgeId}/removeChannel
>
>>>> into:
>>>>
>>>> POST /channels/{channelId}/bridge
>>>> DELETE /channels/{channelId}/bridge
>>>>
>>>> It feels like it makes more sense to control a channel within the
>>>> /channels namespace. Specifically since you have to pass the channel
>>>> id to the bridge.
>
> This isn't really a channel control; there are two objects involved in
> the operation. So you're controlling the channel and the bridge.
>
> For a /bridge operation on channels, you would still need to provide
> the bridgeId, so I don't think you've gained anything at all.
>
Correct, POST /channels/{channelId}/bridge would accept a bridgeId variable.
> 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.
>>> If it was changed to the above we lose that functionality. That's the thing
>>> that springs to mind. I'm slightly more inclined to like it on the bridge
>>> because I find it describes things more, but *shrug*.
>>>
>> Interesting, so I think this brings up a larger point, handling builk
>> operations within the ARI. I guess the argument could be made how to
>> we decided when to implement bulk operations within the ARI vs having
>> the application handle it. I agree that reducing multiple HTTP calls
>> would be a good idea is your application is heavy in that aspect,
>> however I can also see the flip side of just having the application
>> cycle through the POSTs.
>
> There are a few API's that are marked as 'allowMultiple' in the
> api-docs. I don't think this comes out in the wiki docs, though (see
> ASTERISK-22704).
>
Will check it out.
>> What other functions handle BULK things? I don't really see any
>> others. Personally, I'd rather implement single operation functions
>> to start, then move to implement bulk operations.
>
> They should be handled on a case-by-base basis. Adding multiple
> channels to a bridge seems like an obvious need, though. The best
> remote call is the one you don't make.
--
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger
