On Thu, Oct 24, 2013 at 10:04 AM, Ben Merrills
<b.merrills at mersontech.co.uk>wrote:
> That makes sense! ****
>
> ** **
>
> At the end of the day, I should only be getting information I can do
> something about, by default. And yes, I agree that it makes sense to
> incorporate some options for the filtering too.****
>
> ** **
>
> Ben****
>
> ** **
>
> *From:* asterisk-app-dev-bounces at lists.digium.com [mailto:
> asterisk-app-dev-bounces at lists.digium.com] *On Behalf Of *Kinsey Moore
> *Sent:* 23 October 2013 22:06
> *To:* Asterisk Application Development discussion
> *Subject:* ARI Global Data Accessibility Changes****
>
> ** **
>
> Hello App Developers,
> We have been thinking about what information is exposed via the ARI
> requests for lists of channels (GET /ari/channels) and bridges (GET
> /ari/bridges). Currently, these requests return all information about any
> channel or bridge in the system.
>
> As an example, imagine you have channels SIP/Alice and SIP/Bob in the
> Stasis() application being bridged by ARI-created bridge Foo. In the same
> system, you also have channels SIP/Charlie and SIP/David being bridged by
> Dial()-created bridge DialBridge. When you GET /ari/channels, you will
> receive:
> [
> { "name": "SIP/Alice", ... },
> { "name": "SIP/Bob", ... },
> { "name": "SIP/Charlie", ... },
> { "name": "SIP/David", ... }
> ]
>
> When you GET /ari/bridges, you will receive:
> [
> { "id": "Foo", ... },****
>
> { "id": "DialBridge", ... }
> ]
>
> This situation is non-ideal since channels SIP/Charlie and SIP/David and
> bridge DialBridge can not be acted upon via ARI. We propose limiting these
> queries to channels and bridges which ARI can affect. In this case, the
> /ari/channels query would return:
> [
> { "name": "SIP/Alice", ... },
> { "name": "SIP/Bob", ... }
> ]****
>
> The /ari/bridges query would return:
> [
> { "id": "Foo", ... }
> ]
>
> The rework would also include an optional filter parameter for ARI user or
> Stasis application to increase the available granularity.****
>
>
> Kinsey Moore
> Digium, Inc. | Software Developer
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US ****
>
> _______________________________________________
> asterisk-app-dev mailing list
> asterisk-app-dev at lists.digium.com
> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
+1 - I'd still want to be able to access information about the whole system
though - whether this is done with extra headers, as having filtering type
stuff via params just doesn't feel right
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131024/455f25f7/attachment.html>
