[asterisk-bugs] [JIRA] (ASTERISK-22838) ARI: Implement device state API

[Kevin Harwell (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-22838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kevin Harwell closed ASTERISK-22838.
------------------------------------

    Resolution: Fixed
    
> ARI: Implement device state API
> -------------------------------
>
>                 Key: ASTERISK-22838
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22838
>             Project: Asterisk
>          Issue Type: New Feature
>      Security Level: None
>          Components: Resources/res_ari
>            Reporter: Matt Jordan
>            Assignee: Kevin Harwell
>      Target Release: 12.0.0-beta2
>
>
> This issue is to create the data model and implement the functionality for a device state resource in ARI. This approach should follow the second proposal on the blinky light discussion page on the Asterisk wiki:
> https://wiki.asterisk.org/wiki/display/AST/Blinky+Lights+API#BlinkyLightsAPI-Proposaltwo%3AFirstclassresources
> Specifically, this should include the following:
> h3. Updates to the data model
> # A new resource, device-states, should be added that represents the state of a device. It should have both a name and a state. The state should be the string representation of the state enumeration in Asterisk.
> ## A new object should be added to the device-states resource for DeviceState:
> {noformat}
> DeviceState
> name: string
> state: string {}
> {noformat}
> ## Operations should be added to the Devices resource that lets a user manipulate the device state of some Device that they can control:
> || Method || URL || Return Type || Description ||
> | GET | /device-states/\{deviceName\} | DeviceState | Retrieve the current state of a device |
> | PUT | /device-states/\{deviceName\} | void | Change the state of a device controlled by ARI. Note that this implicitly creates the device state. |
> | DELETE | /device-states/\{deviceName\} | void | Destroy a device-state controlled by ARI |
> # An event should be added to the events resource for changes in device state.
> {noformat}
> DeviceStateChanged
> device_state: DeviceState
> {noformat}
> Bindings should be generated from this resource and the data model.
> h3. Subscriptions
> The Applications resource should be updated to allow subscribing to device states. Any device state, ARI controlled or not, can be subscribed to. Subscriptions to device state should have the same control mechanism as other subscriptions in that resource.
> h3. Implementation
> ARI should provide a custom device state provider. This device state provider can be used to comprise an extension state in the same way as other device state providers. The {{Custom:}} device state provider can be used as a model of this, as it is roughly analogous to how the ARI controlled version will function.
> The custom device state provider should be prefixed with {{Stasis:}}. It should be cachable.
> A PUT operation should publish the state for the specified device to the {{Stasis:}} device state provider. This will implicitly create the device as well in the Stasis cache.
> A GET operation should return the last known value of any device state in the system.
> A DELETE operation should clear the specified {{Stasis:}} device state from the cache and remove any other persistent storage of the device state. For example, if the entry was stored in the AstDB, this should remove the value from the AstDB.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira