Changing POST /bridges/{bridgeId}/addChannel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Asterisk SS7]     [Asterisk Announcements]     [Asterisk Users]     [PJ SIP]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Linux API]

  Powered by Linux