[asterisk-app-dev] Changing POST /bridges/{bridgeId}/addChannel

[David M. Lee]

On Oct 16, 2013, at 1:20 PM, Paul Belanger <paul.belanger at polybeacon.com> wrote:

> So, I actually tried this last night, using multiple channels but here
> is the issue that I ran into with bulk.  I have a list of channels,
> some that we in stasis and some not, addChannels failed.  However, I
> was surprised to see that no actually channels made it into the
> bridge, instead I got back a generic message about channels does not
> exist.  

In general, channels need to be in Stasis() in order for ARI to work
on them.

For bulk operations, it's best to do 'all or nothing' as much as
possible. There's no HTTP response code for "it sorta worked" :-)

The error response should be more specific, listing the channels it
had a problem with. Mind opening an issue for that in JIRA?

> Of course, this now opens up the issue of how to tracking
> which channel was the issue and generate error messages / return
> codes.  Now we are starting to move into more complex sceneries which
> is all good, but now more and more logic has to be created to handle
> it.

When the complexity is overwhelming (such as is the case with the
/dial operation), I agree. But this is a case where the complexity can
be completely contained. The function for implementing a bulk add is
currently ~30 lines of code. Adding failing channels to the error
message would probably be another 10 lines of code.

> So, going back to the point of single vs bulk, I think we should focus
> on the single operation, have said library or application you are
> working with take the hit and generate the additional request and once
> we see how people are using the ARI, then work to optimize performance
> issues but adding specific bulk functions.

But we also need to be careful that we don't paint ourselves into a
corner with our decisions. It's not about entirely about optimizing.
It's also about keeping the API simple. And keeping it flexible for
the future.

The RESTful-purist method for adding/removing channels hinders the
bulk add/remove use case dramatically. But the current API doesn't
hinder anything; it just makes the REST purists cringe a little.

> Because honestly, if we are saying the work lot need for additional
> HTTP requests are going to hinder asterisk, then I think we have a
> bigger issue at play.  Then to me, we move http out side of asterisk
> and write directly to the messagebus and have asterisk deal with it
> then.

We just built this thing. Don't give up on it yet!

These are the same challenges you will have with any remote API, not
just RESTful HTTP.

-- 
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