ARI Global Data Accessibility Changes

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

 



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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131024/65cf1250/attachment-0001.html>


[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