Work Item Description

Work Item Title	Working Group	Registration Name	Version number
Generic Open Terminal API	CD WG	GotAPI	1.0

OK, so why now?

Several aspects are driving the motivation to initiate a specific work item for the Device API Framework concept in OMA:
The existing body of work and expanding work program need alignment, or at least to be captured as key inputs to the development of a common framework
Common aspects of the framework approach need technical and deployment focused consideration
Increase in OTT services and evolution of device platform strategies (e.g. SPDY proxies) that risk further relegating access / mobile networks to a bitpipe role, with little or no policy or service enablement ability
In general, the continued need to ensure that OMA enabler based services are not siloed (unless chosen to be so by specific deployments), but are API-enabled at all important access points, including the end-user device

Work Areas:

Guidelines that list/explore different ways Device APIs may be specified and implemented: issues/options to consider when a Device API is specified; protocols (http, sse, websockets, etc); security options (OAuth2?); use by enablers e.g. for device-to-device communication features of the enabler (e.g. see [1])
Architecture and specifications for an API framework based upon a localhost API server exposing HTTP-based APIs to apps running in web browsers and as native apps (including but not limited to hybrid native/web apps).
An API discovery mechanism (e.g. Webfinger, see [2]) for flexible support and deployment of APIs on the device
Supporting assets, e.g. managed by the OMA code pool initiative, enabling abstractions of common API functions (e.g. discovery, access, session management)
A registry of well-known API resources for OMA enablers, to be maintained as part of the OMNA.
Specification of API exposure patterns that are in general globally applicable to native device platforms.
While there is little chance of aligning native device platform APIs, and distinct native API bindings will be needed for different platforms (though perhaps not defined by OMA), there is value in at least establishing API exposure patterns that are in general globally applicable, with the resulting dialog being useful for identifying where the major pattern-support gaps are across native platforms.

[1] OMA-CD-2013-0094R01-INP_Addressing_SNEW_Device_APIs_requirements [2] OMA-TP-2013-0293-INP_Discovery_mechanisms_for_OMA_enablers

Device APIs are exposed by a resource residing in or running on a Device (e.g. a client of an Enabler running on a mobile device, such as Mobile Codes)
Three options for Device API exposure
Browser-based virtual API server (e.g. WRAPI)
Local API server exposed by OS or Native App (e.g. OpenCMAPI, DMClientAPIFw)
Local HTTP API server (local web server)