The idea is to expose a hardware resource as an API. What an API requires
is a URI and parameters. With this assumption - we can define below URI for
the device operations API -
{device-id}/{resource}/{operation}?param=param
With this URI scheme- let's look at how an exposed Buzzer looks like -
rpi1/buzzer/buzz?status=ON
Couple of things I am trying to figure out on this is the verbs used as the
{operation} parameters. For example are we going to call buzzer/buzz and
buzzer/unbuzz? Or look into an option where we give a status parameter to
the API resource?
*Implementation*
On the implementation side - the device will poll an endpoint on the
server checking if new operations are available to be performed. If
operations are available it will perform reverse HTTP binding and obtain
JSON based operations. Below is a sample payload -
{
"operations": [
{
"URI": "rpi1/buzzer/buzz?status=ON",
"data": {
"timeout": "120000"
}
},
{
"URI": "rpi1/led/switch?status=ON",
"data": {
"timeout": "120000",
"color": "RED"
}
}
]
}
The device will return a payload like below -
{
"feedback": {
"rpi1/buzzer/buzz?status=ON": {
"status": 200,
"data": {}
},
"rpi1/led/switch?status=ON": {
"status":
4
00,
"data": {
"error": "Color specified is not available"
}
}
}
}
WDYT?
--
Chan (Dulitha Wijewantha)
Software Engineer - Mobile Development
WSO2 Inc
Lean.Enterprise.Mobileware
* ~Email duli...@wso2.com <duli...@wso2mobile.com>*
* ~Mobile +94712112165*
* ~Website dulitha.me <http://dulitha.me>*
* ~Twitter @dulitharw <https://twitter.com/dulitharw>*
*~Github @dulichan <https://github.com/dulichan>*
*~SO @chan <http://stackoverflow.com/users/813471/chan>*
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
