In this paper we outline the challenges of Web API management in Internet of Things (IoT) projects. Web API management is a key aspect of service-oriented systems that includes the following elements: metadata publishing, access control and key management, monitoring and monetization of interactions, as well as usage control and throttling. We look at how Web API management principles, including some of the above elements, translate into a world of connected devices (IoT). In particular, we present and evaluate a prototype that addresses the issue of managing authentication with millions of insecure low-power devices communicating with non-HTTP protocols. With this rst step, we are only beginning to investigate IoT API management, therefore we also discuss necessary future work.
of the envisioned strength of the IoT will emerge when data from multiple sources can be aggregated, analysed and acted upon. This will increase the demand for IoT devices to communicate with open Web APIs.
Our work addresses the new problem of adapting the principles and technologies of Web API management to the landscape of the IoT, which poses challenges stemming from the great numbers and low power of IoT devices, compared to typical full- edged clients for Web APIs. The problems we are addressing can be clearly stated: { What is the impact of the Internet of Things onto Web APIs and Web API
Management { How do IoT devices identify themselves to Web APIs over IoT protocols? { How can we add IoT protocol support to existing Web API Management systems? { What is the impact of adding identity, usage control and analytics to existing IoT protocol interactions?
This paper provides three clear contributions: rstly, the identi cation of new challenges that emerge from the use of Web APIs from IoT devices, especially those around authentication, usage control and analytics. Secondly, we have implemented a prototype which we believe is the rst of its kind to add support for IoT speci c protocols to API management systems. Finally we provide early experimental data on the performance of this prototype.
The rest of the paper is laid out as follows. In the next section, we look more closely at the area of Web API Management. We then we review related work that gives us a basis for de ning in Section 4 the unique challenges of Web API management for the IoT, especially in connection with binary protocols such as MQ Telemetry Transport (MQTT) or the Constrained Application Protocol (CoAP). Section 5 introduces our prototype, a messaging gateway we call IGNITE, designed to allow us to evaluate the viability and performance of our approach; in Section 6 we present the design and results of our performance experiments. We conclude the paper in Section 7 with a summary and a discussion of further work we expect in this open research area. 2
There is no universal de nition of this space, and little academic research as
yet, but the authors' industrial experience in this area, together with a review
of [
Level Agreement (SLA) or other factors. { Monitoring the usage of speci c clients in order to be able to limit access or charge for API usage.
One of the key aims of API Management is a desire to manage these aspects orthogonally from the creation of the API itself. This is a major bene t to developers or organizations that wish to expose APIs, because these capabilities can be added in a standard way to their systems without requiring custom development that is speci c to the application or business logic.
This is often achieved by the use of a pattern called a \reverse proxy", where the client believes it is connecting to the API itself, but the reverse proxy intercepts these calls, and acts upon them before passing them onto the \target" API. This pattern of infrastructure is also often known as a server-side gateway. 3
While there is a great deal of industrial e ort and research on Web API
management, the academic literature is sparse. In the industrial sector, much of the
literature is provided by vendors. However, the report by Forrester [
In the IoT space, there are a number of e orts around creating open APIs for
IoT: for instance, HyperCat [
There are a number of existing IoT gateways, including [
We identi ed two signi cant gaps in the current literature and existing work
in this space. Firstly, most of the work on using APIs with IoT are very limited:
there is a common assumption that devices will only communicate with a single
API, and there is no discussion of management of these APIs beyond access
control. In the access control space, there is a reliance on using outdated models
of authentication and authorization (passwords and/or client-side certi cates)
that are not suitable for device-to-server communication. Two papers address
this with token-based authentication schemes: in [
Secondly, when looking at the API Management related work, we found no research that addresses how API Management techniques can be used in the face of IoT speci c challenges, especially when using IoT-friendly binary protocols such as MQTT and CoAP. These protocols are important for IoT because of the lower requirements for energy and the lower cost of components required to support them. 4
There is no accurate number of connected devices, but the best estimates all
agree that there are more devices currently than humans on the planet. Cisco
forecasts that there will be 50 billion connected devices by 2020 [
From our experience working with commercial customers of Web API management software, we nd that most Web APIs have tens, hundreds or maybe thousands of known clients. These clients act as machine-to-machine systems where one Web server connects to another Web server.
Most new Web APIs are working with the OAuth2 [
Therefore we envisage that IoT devices will be more likely to need their own
OAuth2 credentials per device. It is impractical to think that these client keys
will be issued manually to the IoT devices: this process must be automated. This
is enabled by the extension to the OAuth2 speci cation called Dynamic Client
Registration (DCR) [
We are not aware of any API yet in production where millions of devices each have their own API key, their own set of throttling measures, etc. It can therefore be seen that API management systems will need to evolve to support very large numbers of keys, with millions or even tens of millions of concurrently connected devices.
Another challenge is that IoT devices are often low-powered and reliant on
low energy usage. Protocols such as MQTT and CoAP are lower in bandwidth
which has a direct e ect on energy usage, especially in wireless transmission
scenarios. Nicholas [
In summary, our work is addressing how to adapt the existing Web API management capabilities to support: { Large numbers of clients, each with their own credential. { Devices communicating with public APIs via binary and low-energy protocols such as MQTT and CoAP. { Usage control, access control, throttling and other API management techniques applied to IoT scenarios.
{ How to apply these capabilities orthogonally to existing systems.
To solve these issues we are building a system that allows using the capabilities of existing API management solutions with IoT protocols. We call the system IGNITE (Intelligent Gateway for Network IoT Events)1. Our initial work focuses on the MQTT protocol, but in future we intend to extend this to CoAP.
For our proof-of-concept prototype, we extended three major existing open
source projects:
{ The WSO2 API Manager [
As of March 2015, upcoming releases of both the WSO2 API Manager and the MITREid-Connect projects plan to support using these two projects in conjunction with each other. Both projects are written in Java.
In conjunction with these projects we have created an API management gateway for IoT | a reverse proxy for IoT protocols that plugs into the existing key server architecture and monitoring capabilities.
We currently have built a rst prototype of this gateway in Python and we are porting it to Java to improve performance. Figure 1 shows the overall architecture with the capabilities of the existing projects plus our added capabilities.
The IGNITE component implements the following logic: On a CONNECT packet arriving, it extracts the OAuth2 Bearer token from the username eld in the packet. It then invokes the Token Introspection service on the MITREid-Connect server to validate the token. If the token is valid, the gateway replaces the token in the request with the userid returned from the introspection call, and forwards the request on to the existing MQTT Broker, which may implement its own validation checks as well. If the token is invalid or no longer active, the IGNITE 1 The source code is available at https://github.com/pzfreo/ignite responds to the client with a packet that indicates that the credential was invalid (a CONNACK packet with ReturnCode=5).
The monitoring and usage control/throttling aspects of IGNITE are still in development. 6
To test the system, we evaluated the performance of this system compared to a direct call to the MQTT broker. In this case, the MQTT broker was not running any authentication of its own, so the comparison is not completely like-for-like. Figure 2 shows the architecture of the test set-up.
We used the open source Mosquitto [
The tests were all run on a single machine2 using the localhost networking. The gateway tests include both the more functional Python prototype of IGNITE and an early prototype of the Java version. The tests show the average result over 1,000 CONNECT/CONNACK messages and 10,000 PUBLISH messages, in both cases giving the system time to warm up before capturing timing data. The QoS 1 and 2 tests inherently capture the use of PUBACK, PUBREC, PUBREL, and PUBCOMP messages. The focus on connection was because the authentication step during connection is where the most work takes place, and on publication because this is the most used ow in MQTT, as subscriptions are rare compared to publication. (a) CONNECT (b) PUBLISH
The CONNECT results are shown in Figure 3a. The results show that the overhead of using the Python IGNITE for CONNECT is around 7,700 s per request. Given that this includes a HTTP REST call to the key server this is not unexpected. In the WSO2 API Manager this overhead has been reduced by implementing a binary key validation protocol instead of HTTP. However given that MQTT is a persistent connection compared to existing Web API gateways and HTTP where each request needs to be validated we feel this is a very e ective result. We did not (yet) implement caching of token introspection results which could improve this considerably.
The PUBLISH numbers (Fig. 3b) show a much lower overhead. For QoS0 the overhead of going through the IGNITE is around 11 s. The QoS2 case has 2 Mac OS/X 10.10 running on a 3Ghz Intel Core i7 with 16Gb RAM and SSD storage a signi cant higher overhead due to considerably more complex message ow. Even in this case the overhead is less than 1500 s and the preliminary data from the Java implementation shows an overhead of less than 60 s. Note that at this stage we have not yet implemented usage control and monitoring into the PUBLISH ow so these numbers do not yet re ect the full workload required. On the other hand there is as yet no optimisation of this prototype code.
To put these numbers into perspective, the typical overhead of such a
gateway in the HTTP world is around 500 s without implementing any OAuth2
token introspection [
In this paper we have outlined the challenges around applying the newly emerging area of Web APIs and Web API to connected devices and the Internet of Things. We outline our model of enhancing existing Web API management systems with a new gateway | IGNITE | that focuses on IoT protocols and demonstrates how protocols such as MQTT can be integrated into existing API Management models with some success, in a completely orthogonal manner. In addition, the model of the server-side IoT gateway that we have introduced with IGNITE o ers a considerable number of possibilities for managing usage control, access control, monitoring, etc.
We have identi ed a number of areas for future research. There is work on improving the IGNITE: to support CoAP, to optimize performance; to integrate into the monitoring framework; and to support throttling of tra c. In addition we believe there is considerable scope for research to be done on description languages for using MQTT and CoAP for IoT Web APIs.
Finally we present preliminary data on performance which shows that the overheads of such approaches are reasonable even before optimisation, caching and other techniques are introduced. 8
The travel expenses of presenting this research paper were funded by the University of Portsmouth, Faculty of Technology Research Capital Investment Fund (RCIF) number 46175.