[asterisk-dev] Dynamic server side event type filtering in ARI
Kevin Harwell
kharwell at digium.com
Fri Dec 14 11:33:39 CST 2018
On Thu, Dec 13, 2018 at 3:42 PM George Joseph <gjoseph at digium.com> wrote:
>
>
> On Thu, Dec 13, 2018 at 2:27 PM Kevin Harwell <kharwell at digium.com> wrote:
>
>> Greetings,
>>
>> I'm looking into adding the ability for an ARI application to dynamically
>> control which event types it would like sent to it[1] (i.e. server side
>> event type filtering). I'm currently leaning toward implementing this as a
>> blacklist. I believe doing so would ease the development burden on the
>> Asterisk side as well as on the application side of things while
>> maintaining current application received event type expectations. Here's a
>> proposed REST interface:
>>
>> GET /applications/{applicationName}/excludeEventFilters
>>
> .
> excludeEventFilters sounds like you're excluding event filters. What
> you're operating on is an eventExclusionList
>
How about eventExclusions? I don't have a real problem with using the world
"List", except it breaks our convention. Everywhere else we just use
plurals.
> Returns a list of exclude event filters.
>>
>> POST /applications/{applicationName}/excludeEventFilters
>>
>> Using a json object as a body parameter create a list of exclude
>> event filters. This will overwrite any existing filters list. For now the
>> json object *might* look something like the following:
>>
>> { types: [ eventType, eventType, ...] }
>>
>
> When you POST, you're asking the object to take some action.
> If you want to use POST, then the json blob should contain an "add" list
> of types and a "remove" list of types.
>
> We SHOULD be using PUT to add or replace an entire list.
>
I'm not a REST expert by any means, but I thought POST aligned more with
create and PUT create/update. But I guess since we are working on the whole
list then we can get away with just a PUT, and as you say it will add or
replace/update the entire list.
>
>
>> By making it an object this would make it possible to add more filtering
>> in the future without having to update the definition.
>>
>> DELETE /applications/{applicationName}/excludeEventFilters
>>
>> Remove all filters from the exclude list.
>>
>
> DELETE deletes the list. See below.
>
>> If people wanted I could also add the following?
>>
>> PUT /applications/{applicationName}/excludeEventFilters/{eventType}
>>
>> Add the specified “eventType” to the exclude list.
>>
>> DELETE /applications/{applicationName}/excludeEventFilters/{eventType}
>>
>> Remove the specified “eventType” from the exclude list.
>>
>
> You could DELETE /applications/{applicationName}/eventExclusionList/all
> to delete the event types from the list.
>
I think just DELETE'ing the list is fine. I was more thinking from an
Asterisk coding perspective at the time where we'd probably just clear the
internally stored collection.
>
>
>> Naming is hard, but I've used “exclude” in order to signify that matches
>> on a specified filter would block messages being sent to the application.
>> “Filters” I've used because it's filtering the messages that are being sent
>> to the application, and later we might want to filter off more than the
>> event type name.
>>
>> Anyhoo thoughts, opinions, alternative ideas are most welcome.
>>
>> Thanks!
>>
>> [1] https://issues.asterisk.org/jira/browse/ASTERISK-28106
>>
>> --
>> Kevin Harwell
>> Digium - A Sangoma Company | Senior Software Developer
>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
>> Check us out at: https://digium.com & https://asterisk.org
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>> http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>
>
> --
> *George Joseph*
> Digium - A Sangoma Company | Software Developer | Software Engineering
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
> direct/fax: +1 256 428 6012
> Check us out at: https://digium.com · https://sangoma.com
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-dev
--
Kevin Harwell
Digium - A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: https://digium.com & https://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20181214/2194ec1f/attachment-0001.html>
More information about the asterisk-dev
mailing list