APIs for WSNs can be provided at different levels, including the operating system level and the network level. An example of such an integration is how TinyOS provides an API that allows the application layer to access the functions that are provided by the operating system. At a network level, an API can provide an interface for the application layer to access the routing table, enabling it to find the best path for data transmission to be done. This can be implemented by different standard protocols such as MQTT or CoAP, two application protocols that we discussed in Chapter 3, Integrating Application Protocols.
APIs allow different software components to be integrated with ease and help make the services that are provided by one provider interoperable with others, such as with the cloud or other sensor networks. This, in turn, helps with developing and maintaining the applications, as well as provisioning a well-defined interface for the functionality that is provided. Despite this, there are some major challenges, two of which are complexity and security. APIs introduce another component into your architecture, so it will affect how the routing and interaction between components will work. You should understand how the API will interact with your other components and whether you truly need it for your system. Furthermore, if not implemented securely, it may pose a security risk. Often, this must be mitigated with secure communication protocols such as HTTPS and through the implementation of authentication and authorization.
Types of APIs
In this subsection, we will highlight two popular APIs that are used in developing WSNs.
REST APIs
REST is a popular architectural style of building web services and is a popular API for use within WSNs. It provides a way for the application layer to access the functions of the sensor nodes and the network, providing functions such as data collection, power management, and communication through HTTP methods such as PUT, GET, POST, and DELETE.
It is based on widely used standards, namely HTTP and URI, making them easy to implement and use. This also makes it easy to integrate with other systems. It also allows you to remotely configure and manage sensor nodes, which is useful for managing the dynamic nature of WSNs. Furthermore, it helps provide security through security mechanisms such as SSL/TLS and works when authentication and authorization must be implemented.
Despite this, it has its own set of challenges, such as the overhead that is caused by using HTTP and URI – that is, additional message headers will be introduced, which would cause various issues within WSNs, given that bandwidth is often a resource that we are trying to optimize. They are also less power-efficient compared to other APIs:
Figure 5.4 – REST API connection with an IoT service platform
An example of its implementation within one such system can be seen here:
Figure 5.5 – A flow diagram showing the implementation of the REST API
As we can see, the interaction depends on a device ID and account credentials being sent through to the administrator. The administrator then sends these details through the REST API to the AWS cloud service, which, in turn, sends an email based on the information that was received. Within WSNs, we see a similar pattern with its implementation, given that we will also be forwarding the information this way.
