# Bindings and RESTlets: A Novel Set of CoAP-Based Application Enablers to Build IoT Applications
## 6 Implementation and Evaluation
### Implementation
#### 6.1.2 RESTlets  
The RESTlet concept, as discussed above, makes use of bindings to build (parts of) IoT applications by performing processing tasks and exchanging raw values and (semi) processed data between devices. In order to enable nodes to support RESTlets, some modifications have been made to both Erbium and CoAP++. The main modifications are discussed below.  
The application logic of RESTlet, which acts on the data inputs (and the control inputs) to produce outputs, has been implemented for every node that potentially hosts the RESTlet. Every RESTlet defines its own processing function and hence one processing function per RESTlet is defined. Generic functions that manipulate the data and control inputs have also been defined. A POST request to a specific resource initiates the instantiation of the RESTlet instances and the dynamic creation of associated resources. The /r resource is defined for this purpose. Moreover, since Erbium does not support the dynamic creation of resources, this functionality has been added. In order to differentiate one RESTlet instance from the other, detailed information about every instantiated RESTlet needs to be stored. Therefore, a data structure for storing the RESTlet name, the number of data inputs, the number of control inputs, the number of outputs, and the memory address of the processing function has been defined. This data structure may also store the latest values of the data inputs, control inputs and outputs if required. Finally, a callback function that is called for further manipulation of the resources and sub-resources has been defined. The flow chart of this callback function is shown in Figure 11.  
Each time a request for the /r resource arrives, it is forwarded to the callback function in order to see which sub-resource is referenced and an appropriate action is taken. Based on the URI-PATH of the request, the function will be able to identify for which sub-resource the request has been sent. A PUT request for the data input (in) initiates execution of the processing logic, which, in turn, notifies observers in case the output changes. Sending a PUT request to the control input (con) results in changing the identified control input. GET requests to any of the sub-resources may be used to retrieve the current value. All outputs have been made observable in order to allow binding relationship between the RESTlet and devices (or other RESTlets).  
Putting it all together, once all logic for a particular RESTlet has been defined and implemented, applications may instantiate RESTlets on a specific node by sending a POST request to the _/r_ resource and specifying the name of the RESTlet, the number of data inputs, control inputs and outputs in the payload as follows:  
_RN = <RESTlet Name>; IN = <# Data inp>; CON = <# Control inp.>; OUT = <# Output>_  
For example, a POST request sent to a node with RN = AND; IN = 2; CON = 2; OUT = 1; as payload, creates the AND RESTlet with two data input, two control input and out output resources. The five resources will be referenced as /r/0/in/0, /r/0/in/1, /r/0/con/0, /r/0/con/1, and /r/0/out/0 in all further communications. Subsequent POST requests create RESTlet resources that are identified by changing the number next to the _/r_.