Architecture of GotAPI

The objective of the framework realized by GotAPI is to unify the interface for web applications run on web browsers and native applications run on smartphone OSs to access various external devices.

In principle, in order to realize collaboration with an external device, one needs to develop software for collaboration suited for the specific device. Some device manufacturers provide software development kits (SDKs) for native applications for smartphones. Naturally, however, there is no unified way of using SDKs provided by different device manufactures. Therefore, application developers had to incorporate an SDK in the developed application per corresponding device. Further, because each manufacture prepares proprietary interfaces even for devices providing similar functions, there is limitation in the reuse of source codes.

On the other hand, web applications run on web browsers have had limitation in collaboration with external devices from the beginning. Although a large number of standard APIs have been implemented in the browsers in recent years, implementation of Bluetooth APIs etc. necessary for device collaboration have not made much progress, and therefore, only limited devices can be collaborated.

In order to solve these challenges, GotAPI provides a framework to relay collaboration with external devices by employing HTTP.

Inside smartphones, an HTTP server called GotAPI Server is activated. In practice, from the viewpoint of OSs, GotAPI Server is installed as a native application. GotAPI Server provides REST (Representational State Transfer)-based APIs to applications.

Software called plug-ins take care of access to each device. As is the case for GotAPI Server, from the OSs’ viewpoint, the plug-ins are also installed as native applications.

GotAPI adopts an architecture that enables flexible addition of devices that can be accessed by separating GotAPI Server that relays an API request and response and software that actually communicates with external devices.

For application developers, GotAPI facilitates development of applications taking care of collaboration with devices. For device manufacturers, by providing the environment that enables flexible creation of third party applications, use of the devices is expected to be promoted.

WebAPI

As described, the APIs provide by GotAPI is REST-based, and here, we call them WebAPI. Because WebAPI provides applications with APIs only with standardized communication protocols such as HTTP, multi-platform APIs independent of OSs can be provided.

As for responses for WebAPI, JSON, which is generally used in web, is adopted. It has affinity especially to JavaScript-based web applications run on web browsers.

WebAPI specified in the OMA GotAPI specification specifies concrete APIs such as authentication of applications and security measures as well as data containers actually used when collaborating with devices. The data containers specify communication between applications and GotAPI Server as well as communication between GotAPI Server and plug-ins.

However, currently, the OMA GotAPI specification does not specify concrete WebAPI exchanged between applications and plug-ins. This is the reason for the OMA GotAPI specification to be called framework.

Standardization of WebAPI on the concrete plug-in functionality has yet to take place. In OMA, examination on concrete API specifications has started from healthcare. Further standardization is expected going forward.

Plug-ins

Here is a little more detailed description as to why plug-ins have been adopted in GotAPI as an architecture.

The first purpose is to absorb the differences of communication protocols among devices. Communication systems of devices collaborated with smartphones vary. Not only the lower communication layer such as Bluetooth and Wi-Fi but everything varies including communication protocols, data containers and meanings of data values. Such differences greatly impact development cost in application development. The differences are absorbed by the plug-ins, and to GotAPI Server, results are returned by using the standardized interface. This enables applications to collaborate with external devices via unified interface without being aware of the differences of communication systems of external devices.

The second purpose is to provide the same WebAPI for the same usage even in case devices are different. As described above, currently, only the framework has been standardized in the OMA GotAPI specification and this aspect has not been specified. Pursuit and examination of a unified WebAPI is one of the main themes of the consortium.

DeviceConnect

DeviceConnect is one of the implementations (software) based on the GotAPI specification that has been described. DeviceConnect was developed by NTT DOCOMO and provided as open source software in GitHub under the MIT license. Anyone can contribute in the improvement of the source codes and development such as addition of new functions. Also by using the source codes, one can freely use the mechanism of GotAPI and develop applications.

DeviceConnect has already added functions which have not been standardized in the OMA GotAPI specification. For example, in the GotAPI specification, a framework to asynchronously receive events has not been specified. Therefore, DeviceConnect has added the role of a WebSocket server to GotAPI Server and provided a framework for asynchronous event reception.

Results of the work on DeviceConnect are planned to be proposed for standardization in OMA.

API for device access

In DeviceConnect, a large number of APIs for individual device access, which have not been specified in the GotAPI specification, are available. APIs such as proximity detection, detection of orientation of devices, temperature detection, obtaining battery information, vibration, turning on/off lights, replay control of music and videos, sound and video recording and photo shooting have already been implemented. Of course the APIs introduced here are not exhaustive and other WebAPIs are also available. More WebAPIs are expected to be added going forward.

Care has been taken for these WebAPIs so that the same API can be used for the same purpose. For example, in case one wants to obtain the status of batteries, instead of preparing an API per connected device type, a unified API will be provided to all the devices. Going forward, we expect that plug-ins for various devices will be added, and in due course, we expect that the APIs will improve and incorporate truly needed functions. And that will also be reflected in the standardization activities.

Lineup of plug-ins

In DeviceConnect, various plug-ins are already available and they are all publicized in GitHub: Chromecast, Android Wear, Sony SmartWatch 2, pebble, sphero, Hue, IRKit, etc.

Source codes of the plug-ins have been publicized in GitHub, therefore, we expect that plug-ins for products from a large number of device manufacturers will be provided by referencing the samples. Further, in case detailed technical information on the devices are publicized, plug-in development by fans of the products can also be expected.

Device WebAPI Manager

Lastly, we would like to introduce an application to be distributed for DeviceConnect. Only developers can use the source codes, and even GotAPI-supported applications are developed, GotAPI Server and plug-ins must be installed in the smartphones of the users.

Device WebAPI Manager has been prepared as an application to be distributed so that anyone can use DeviceConnect by installing it in Android or iOS.

Device WebAPI Manager has been provided free-of-charge by GClue and it has already been distributed on Google Play and Apple App Store, therefore, anyone can try it immediately.

Device WebAPI Manager has the mechanism that in case Manager corresponding to GotAPI Server or plug-ins are not installed in a user’s smartphone, it guides him/her to install them from the application’s screen so that the user can use applications immediately.