2016 IEEE 5th Global Conference on Consumer Electronics
A Proxy Framework for API Interoperability
in the Internet of Things
Satoshi Asano*, Takeshi Yashiro, and Ken Sakamura
*
Ubiquitous Computing Technology Corporation, YRP Ubiquitous Networking Laboratory, The University of Tokyo
E-mail: satoshi.asano@uctec.com, takeshi.yashiro@ubin.jp, ken@sakamura-lab.org
AbstractWe propose a novel framework for the Internet of
Things (IoT) devices, which aims to realize interoperability
among devices without modification to the devices. Our
framework works as a proxy that accepts standard API requests,
which are translated into device-specific requests using the
conversion rules defined as device-specific profiles. Application
programmers are not required to be aware of the difference of
the APIs of devices thanks to the standard API provided by the
framework. We evaluated our framework and found that our
framework can standardize two different device APIs in practical
scenarios with a negligible impact on response time.
KeywordsIoT; device framework; API
I. INTRODUCTION
The Internet of Things (IoT) is now considered a key
technology to realize an intelligent environment by integrating
physical and cyber objects as a whole system. The number of
IoT-enabled devices (IoT devices) have been increasing
rapidly, and they are designed to communicate with
applications or other IoT devices through the Internet.
In order to realize interconnection among devices and
services in the IoT, interoperability of APIs is considered an
important challenge [1]. Generally speaking, IoT devices from
different vendors provide different APIs, which are non-
customizable and device-specific. Because of this, application
developers need to understand the API specifications of each
device and write specific codes to integrate these devices. For
example, if you replace an air conditioner with another from a
different manufacturer, a smart house application needs to be
upgraded as well to support the new one, even though both
provide the same functionality. Such updates in household
devices can often happen, which makes interoperability in IoT
crucial.
So far, much work has been done to address this problem,
and it can be classified into two categories: semantic [2,3] and
syntactic approaches [4,5]. The first tries to describe semantics
of device APIs as device profiles using Resource Description
Framework derived from the semantic web. By utilizing the
device profiles, programs can understand the meaning of API,
how to use it, which can be used to convert an API to another.
However, it is considered impractical to process description
logics for API conversion, due to its high computational cost
and its limited readability. On the other hand, the latter
approach tries to describe API specifications syntactically,
978-1-5090-2333-2/16/$31.00 2016 IEEE
which enables device profiles to be handled efficiently.
However, none of the existing work based on syntactic
approach is flexible enough to make device APIs interoperable.
In this paper, we propose a novel IoT framework that can
realize interoperability among devices without modification to
the devices. Our framework is founded on a flexible device
profile schema, which can describe conversion methods from
standard API to device-specific API. Using these device
profiles, device manager works as an API translator and
provides transparent access to devices via standard API.
II. PROPOSED FRAMEWORK
A. Design Overview
We have designed and implemented our proposed
framework as shown in Fig. 1. The framework consists of 4
parts: device manager, device profile repository, authorization
manager, and access control manager. Device manager accepts
standard API calls and translates them to device-specific calls
according to device profiles obtained from device profile
repository. In addition, it provides device-search API to find
devices based on functionalities; e.g., listing up all the air
conditioners. Authorization and access control managers are
responsible for realizing integrated security over IoT devices.
Their APIs are based on OpenID Connect 1.0 specification,
which allows device APIs to be integrated with ease in web
applications [6].
B. Device Profile
We designed two types of profiles to describe device APIs
as follows: Generic device Profile (GP) and device Specific
Profile (SP), both of which are based on Open API (OAI)
Our proposed Framework
Vendor specific Authorization
APIs hosted in Device manager
Device
profile
cloud services
repository
manager Access control
manager
Applications
Devices of devices
Fig. 1. Overview of our proposed framework.

specification [7]. GP defines the syntax and semantics of the
standard device API for each device class (e.g., air
conditioners, refrigerators, etc.). It consists of device ID, its
name; device type (actuator, sensor, or transducer),
informative text, version, and the API format. On the other
hand, SP is responsible for describing each specific device
product, and defines the conversion rules from device-specific
APIs to standard APIs defined in GP. It consists of device
model ID, manufacturer ID, and API conversion rules
described using our extended OAI. The list of extensions we
made to the OAI are as shown in Table I, consisting of
conversion information of API path, access method, request
body, and response body. Fig. 2 shows an example of the SP
fragment defined for Philips Hue API [8]. It describes that the
standard PUT /power API accepts parameters named id
and power, and that the device manager converts these
requests to PUT /api/newdeveloper/lights/{id}/state, which
the product natively provides. Request and response
parameters are converted as well, based on the rules given in
x-request-body and x-response-body, both of which can be
written in Ruby Programming Language.
III. EVALUATION AND DISSCUSSIONS
We implemented device manager and device profile
repository using Grape framework, a domain specific
language for creating RESTful APIs in Ruby. Based on this
implementation, we evaluated our framework with respect to
the capabilities of the proposed profiles, the abilities of device
control via standard API, the impact to the response time and
security issues caused by the framework.
As a case study, we created device profiles for Philips Hue,
part of which were as shown in Fig. 2. As can be seen in the
rule, the proposed framework is capable of converting HTTP
access method, request and response bodies, using general
programming language that is Turing-complete. We also
confirmed two different types of lighting APIs can be accessed
using the common API as shown in the URL below:
http://{The hostname of the framework}/api/v1/devices/{The ID of the
device}/api?path=power&method=put&request_params=%7b%22power%
22:true,%22id%22:1%7d
In order to assess the latency caused by the introduction of
our framework, we compared the response times of Philips
Hue API with and without our framework. We measured 100
times and the mean response times were 0.0199 and 0.0053
TABLE I. EXTENSIONS OF OPEN API SPECIFICATION IN SP.
Element name Summary
x-api-type An API type of the device chosen from followings:
Actuator, Sensor, Configurator
x-location An URL of the API
x-access-type An access type according to following rules:
"redirect" when the device provides standard API, or
"eval" in the other case.
x-access-method HTTP access method chosen from followings: GET,
POST, PUT, PATCH, DELETE, OPTION; or script,
which returns a HTTP method.
x-request-body A conversion script of request body from standard
API to device-specific API.
x-response-body A conversion script of response body from device-
specific API to standard API.
2016 IEEE 5th Global Conference on Consumer Electronics
"api": { "paths": { "/power": { "put": {
"parameters": [
{"name": "id", "in": "query", "required": true,
"type": "string"},
{"name": "power", "in": "body", "required": true,
"schema": {"type": "boolean"}}],
"x-type": ["Actuator"],
"x-access-type": "eval",
"x-access-method": "put",
"x-location": /api/newdeveloper/lights/{id}/state",
"x-request-body": {"on":device_request["power"]}",
"x-response-body":
"{"power":#{JSON.parse(device_response)[0]
['success'].values[0]}}"
Fig. 2. Example of SP fragment for Philips Hue API
seconds respectively, with standard deviations of 0.0043 and
0.0015 seconds. The mean delay caused by the framework was
0.0146 seconds. According to a study in usability engineering,
response time of 0.1 seconds is perceived as instantaneous by
users [9]. Therefore, the response time of the framework can
be considered small enough in real usage.
Regarding security, our framework is equipped with user
authorization and authentication based on OpenID Connect
1.0. Only the legitimate users can access device APIs under
the control of access control manager. API conversion rules
are evaluated in a secure sandbox, which makes it impossible
for adversaries to damage device managers by registering
tainted scripts on the framework.
IV. CONCLUSION
We proposed a novel framework for the IoT devices,
which aims to realize interoperability among devices without
modification to the devices. The evaluation results showed
that our framework can standardize two different device APIs
in practical scenarios with a negligible impact on response
time.
REFERENCES
[1] A. Whitmore, A. Agarwal, and L. Xu, "The Internet of Things---A
survey of topics and trends," Information Systems Frontiers, vol. 17, no.
2, pp. 261-274, April 2015.
[2] D. Pfisterer et al., "SPITFIRE: toward a semantic web of things," in
IEEE Commun Mag., vol. 49, no. 11, pp. 40-48, November 2011.
[3] A. Sheth, C. Henson and S. S. Sahoo, "Semantic Sensor Web," in IEEE
Internet Comput., vol. 12, no. 4, pp. 78-83, July-Aug. 2008.
[4] K. Aberer, M. Hauswirth, and A. Salehi, Global Sensor Networks, tech.
report LSIR-2006-001, Global Sensor Networks, 2006.
[5] UPnP Forum. (2015, April). Leveraging UPnP+: the Next Generation of
Universal Interoperability [Online]. Available: http://upnp.org/resources/
whitepapers/UPnP_Plus_Whitepaper_2015.pdf
[6] Nat Sakimura et al. (2014, November 8). OpenID Connect Core 1.0 inco
rporating errata set 1 [Online]. Available: http://openid.net/specs/openid-
connect-core-1_0.html
[7] The Linux Foundation. (2014. September 8). OpenAPI Specification
[Online]. Available: https://github.com/OAI/OpenAPI-Specification/blo
b/master/versions/2.0.md
[8] Koninklijke Philips Electronics N.V. (2016). Philips hue API [Online].
Available: http://www.developers.meethue.com/philips-hue-api
[9] J. Nielsen. (2009, October 5). Powers of 10: Time Scales in User Experi
ence [Online]. Available: https://www.nngroup.com/articles/powers-of-1
0-time-scales-in-ux/