I thought about that. But if we follow an approach where we have only the sensor id and device id on the URI - the API won't be that clear. This is because HTTP verbs itself doesn't make much sense to hardware. I have seen some RESTful APIs exposing operations as resources [1].
[1] - https://developer.github.com/v3/pulls/#merge-a-pull-request-merge-button On Thu, Sep 18, 2014 at 10:25 AM, Paul Fremantle <[email protected]> wrote: > The operation shouldn't be in the URI. That is a highly non-RESTful > approach. > > The URI needs to represent the resource only: > > /{deviceid}/{sensor/actuator-id} > > Paul > > On 18 September 2014 05:51, Chan <[email protected]> wrote: > >> 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 [email protected] <[email protected]>* >> * ~Mobile +94712112165 <%2B94712112165>* >> * ~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>* >> > > > > -- > Paul Fremantle > CTO and Co-Founder, WSO2 > OASIS WS-RX TC Co-chair, Apache Member > > UK: +44 207 096 0336 > > blog: http://pzf.fremantle.org > twitter.com/pzfreo > [email protected] > > wso2.com Lean Enterprise Middleware > > Disclaimer: This communication may contain privileged or other > confidential information and is intended exclusively for the addressee/s. > If you are not the intended recipient/s, or believe that you may have > received this communication in error, please reply to the sender indicating > that fact and delete the copy you received and in addition, you should not > print, copy, retransmit, disseminate, or otherwise use the information > contained in this communication. Internet communications cannot be > guaranteed to be timely, secure, error or virus-free. The sender does not > accept liability for any errors or omissions. > -- Chan (Dulitha Wijewantha) Software Engineer - Mobile Development WSO2 Inc Lean.Enterprise.Mobileware * ~Email [email protected] <[email protected]>* * ~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 [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
