Summary:	ASTERISK-22838: ARI: Implement device state API
Reporter:	Matt Jordan (mjordan)	Labels:
Date Opened:	2013-11-11 10:45:34.000-0600	Date Closed:	2013-12-09 13:38:25.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Resources/res_ari
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	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.
Comments: