[asterisk-app-dev] Changing POST /bridges/{bridgeId}/addChannel
David M. Lee
dlee at digium.com
Tue Oct 15 14:35:00 CDT 2013
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.
And you would have to pass the bridgeId into the DELETE, and passing
params into deletes is just freaky.
>> 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).
> 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.
--
David M. Lee
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com & www.asterisk.org
More information about the asterisk-app-dev
mailing list