3. INTRODUCTION: Web on embedded systems
■ Server enabled devices
■ Client enabled devices
4. MOTIVATION: Challenges of REST API on embedded system
■ Server side challenge
– design fully RESTful API
– standardized REST API among devices
– API maintainability & product lifecycle
– API quality assurance on various clients
■ Client side challenge
– difficulty to understand API domain
– REST API provide too low-level abstraction
– application maintainability to adapt
REST API change
HTTP
HTTP
Internet
REST API
REST API
Web Server Framework
Web Brower Web Runtime
JavaPHPJavaScript
JavaScript
…
HTML CSS …
5. MOTIVATION: Delegate to JavaScript API
■ Server side beneficial
– provides evolvability to fully RESTful API
– leverage standardized REST API
– Node.JS appears to develop server
using JavaScript
– API quality assurance to a target client
■ Client side beneficial
– JavaScript APIs are more friendlier
to client-side developers than REST APIs
– JavaScript APIs provide high-level
abstraction
– wrapper to map REST API to JavaScript
API can maintain the REST API change
HTTP
HTTP
Internet
REST API
REST API
Web Server Framework
Web Brower Web Runtime
JavaPHPJavaScript
JavaScript
…
HTML CSS …
6. OUR APPROACH: Design JavaScript API from REST API
■ 5 steps to design
① Collect use cases
of a REST API
② Extract states
of a client
③ Introduce
the entities
④ Add methods to
an entity
getRadius()
draw()
⑤ Design the method parameters
void draw(
unsigned short x,
unsigned short y,
SuccessCallback scb,
optional ErrorCallback ecb);
WebIDL Specification
7. CASE STUDY: N-Service API
■ N-Service API enables Multi-Screen Service Development
– allows Smart TV incorporating web platform and nearby mobile devices
■ System Architecture
– Inter-application communication w/ REST API & JavaScript API
Source: http://precious-forever.com/2011/05/26/patterns-for-multiscreen-strategies/
8. CASE STUDY: N-Service API
■ Step #1: Collect use cases of a REST API
Source: http://www.samsungdforum.com/
Guide/ref00003/convergence_app_client
totvappcomm.html
Method URI Use case
POST /ws/apps/{appId}/connect Connect to a host application
POST /ws/apps/{appId}/disconnect Disconnect from a host application
GET /ws/apps/{appId}/info
Get the information of a host
application
POST /ws/apps/{appId}/queue
Push a message to a host
application or upload a file
GET /ws/apps/{appId}/queue/devices/{deviceId}
Pop a message of a specific client
device from a host application
POST /ws/apps/{appId}/queue/devices/{deviceId}
Push a message to a specific client
device
POST /ws/apps/{appId}/queue/groups/{groupId}
Push a message to a specific
group
GET /ws/apps/{appId}/queue/groups/{groupId} Retrieve group members
POST
/ws/apps/{appId}/queue/groups/{groupId}
/join
Join a group
POST
/ws/apps/{appId}/queue/groups/{groupId}
/leave
Leave a group
9. CASE STUDY: N-Service API
■ Step #2: Extract possible states of a client and the state relationships
10. CASE STUDY: N-Service API
■ Step #3: Introduce an entity that is responsible for the extracted states and
there transitions
NServiceHostNServiceManager
NServiceDevice NServiceDeviceGroup
11. CASE STUDY: N-Service API
■ Step #4: Add state transitions as methods to the introduced entity
NServiceHostNServiceManager
NServiceDevice NServiceDeviceGroup
connectToNServiceHost()
joinGroup()
sendMessageToHost()
getHostInfo()
disconnect()
sendMessage()
leave()
getMembers()
12. CASE STUDY: N-Service API
■ Step #5: Make the number of method parameters smaller than the parameter
number of the corresponding REST API
[REST API]
POST /ws/app/{appId}/connect HTTP/1.1
SLDeviceID: 12345
VendorID: VendorMe
DeviceName: IE-Client
ProductID: SMARTDev
NServiceManager
connectToNServiceHost()
joinGroup()
sendMessageToHost()
[JavaScript API – synchronous (tentative)]
boolean connectNServiceHost(
DOMString appId,
DOMString slDeviceID,
DOMString deviceName,
DOMString productId
);
[JavaScript API – asynchronous]
[Constructor (NServiceHostInfoInit init)]
interface NServiceHostInfo {
attribute DOMString ipAddress;
attribute unsigned short portNumber;
attribute DOMString appID;
};
void connectNServiceHost(
NServiceHostInfo hostInfo,
NServiceHostConnectSuccessCallback
onsuccess,
optional ErrorCallback? Onerror
);
13. CASE STUDY: N-Service API
■ The order of JavaScript API calls for /connect operation
– NSeviceOwnDeviceInfo interface and corresponding methods are introduced.
14. CASE STUDY: N-Service API
■ Finally, JavaScript API works seamlessly both host and client side.
– below figure shows the ER diagram between client API & host API
15. CASE STUDY: N-Service API
■ Web applications using the JavaScript API
– Mash-up with Open API such as YouTube, flicker, ...
– Sources are freely available HERE
[Family Album]
[Puzzle game]
[YouTube Continue Play]
[Draw Together]
16. CASE STUDY: Lesson learned
■ A security issue using the REST API on CORS-aware browser
– W3C Cross Origin Resource Sharing
■ Usability Enhancement
– Object-oriented JavaScript API is more usable than REST API.
■ Code maintainability
– The client code using JavaScript API is more readable than directly invoking REST API.
■ Better documentation
– JavaScript API provides reasonable document as a REST API’s programming guide.
17. Feel free to contact me if you have any question
hyunghunny@gmail.com