You?re exposing a Subscriber object here, but there?s no associated resource for managing the subscriber. What?s that used for?
> Operations:
>
> GET /topics List[Topic] - list all topics, with optional filter for type
> GET /topic Topic - get information about a specific topic
> DELETE /topic - destroy a topic. This should implicitly unsubscribe all subscribers.
> POST /topics Topic - create a new topic. When you create a topic, you are implicitly subscribed to that topic.
> type: The type of topic to create. Valid types initially would be 'mailbox', 'device', 'presence'
> uri: The URI subscribers will use to subscribe to the topic
> POST /topics/publish - publish an event to a topic. Events are passed as JSON, and are opaque from the perspective of ARI. It would be up to the specific topic types to understand the event packages.
Aside from merging together several potentially separate concerns, there?s a lot of unREST in this proposal :-P
> /applications/{applicationName}/subscription will be updated to allow for an ARI client to subscribe to any topic in Asterisk.
>
> Note that a topic doesn't have to be something created by ARI - Asterisk will create a *lot* of topics by itself. There would be a topic for all mailboxes created by voicemail providers; a topic for all producers of extension state (at a minimum; devices as well); a topic for all producers of presence state. Much like the Endpoints resource, the Topics resource lets an ARI client subscribe to other things in the system other than what is directly in their application, so that the client can choose to have knowledge of the whole system, even if it only affects a part.
>
> This is quite a big project, but a very necessary one. There's only one thing that has to be fixed in ARI before we can do this - namely the ability to POST JSON (thanks Paul!) But other than that, I don't think there are any technical barriers to this approach.
>
> Thoughts? Comments?
By weaving these three concepts together, I worry that in an attempt to make the interface ?easy?, we end up making it complicated. Presence, device state and mwi become hidden in the types of topics you create. Creating individual resources for these topics seems like a simpler, and more clear, approach.
I at least like to see what individual /mailboxes, /devicestates, and /presencestates resource would like like before we attempt to combine them at the API level. If we find that these are three different names for identical API?s, then maybe merging them is a good idea. But my gut tells me that we?ll find subtle differences between them.
I?m not familiar enough with the use cases to put together an API counterproposal.
This seems like a big/important enough topic to get its own wiki page. So I started one: https://wiki.asterisk.org/wiki/x/YQ2UAQ
I?ve put some questions that I have on that page.
--
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
