On Thu, Dec 13, 2018 at 3:42 PM George Joseph <gjos...@digium.com> wrote:

>
>
> On Thu, Dec 13, 2018 at 2:27 PM Kevin Harwell <kharw...@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
-- 
_____________________________________________________________________
-- 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

Reply via email to