Changing POST /bridges/{bridgeId}/addChannel

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

 



On Tue, Oct 15, 2013 at 1:07 PM, Joshua Colp <jcolp at digium.com> wrote:
> Paul Belanger wrote:
>>
>> Anybody have any objections with moving:
>
>
> Yes.
>
>
>> POST /bridges/{bridgeId}/addChannel
>> POST /bridges/{bridgeId}/removeChannel
>
>
> This operation does not add or remove a channel from a bridge. It adds or
> removes multiple channels from a bridge. This can reduce POSTs quite a bit
> depending on application usage.
>
>
>> 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.
>
>
> 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.

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.

-- 
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger



[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