Update of /sources/public/2009/dap/docs
In directory hutz:/tmp/cvs-serv14802/docs
Added Files:
virtual-ws.html
Log Message:
Virtual web services discussion, preliminary document
--- NEW FILE: virtual-ws.html ---
<!DOCTYPE html>
<html>
<head>
<title>Devices as Virtual Web Services</title>
<meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
<script src='../ReSpec.js/js/respec.js' class='remove'></script>
<script class='remove'>
var respecConfig = {
specStatus: "base",
shortName: "virtual-ws",
edDraftURI: "http://dev.w3.org/2009/dap/docs/virtual-ws.html",
// lcEnd: "2009-08-05",
noIDLIn: true,
editors: [
{ name: "Robin Berjon",
url: "http://berjon.com/",
company: "Vodafone",
companyURL: "http://vodafone.com/" },
],
inlineCSS: false,
};
</script>
<script src='../common/config.js' class='remove'></script>
</head>
<body>
<section id='abstract'>
A discussion of the advantages and issues with exposing local data services as REST services
instead as of APIs.
</section>
<section class='informative'>
<h2>Introduction</h2>
<p>
At the beginning of 2010, Mark Miller
<a href='http://www.w3.org/mid/4d2fac901001071847k22a908b6yb4ab71fa37f19c33@mail.gmail.com'>started a discussion</a>
in the DAP WG about whether some of DAP's APIs couldn't be exposed as RESTful web services that would be
somehow localised.
</p>
<p>
While he didn't list which APIs this approach would apply to, one can presume that it would apply
better to those APIs on DAP's charter that provide information services (Contacts, Calendar, Tasks, Messaging,
System Information, Communications Log, Gallery) than to those that may be characterised as
"closer to the metal" (File System, Application Launcher, Capture) or directly integrated with the
system (User Interaction).
</p>
<p>
This document intends to analyse the pros and cons of such an approach, taking into account the
gearing towards information services described above.
</p>
</section>
<section>
<h2>Case Study: Geolocation</h2>
<p>
There is a large body of experience in designing both Javascript and RESTful APIs, but without concrete
examples we will likely nevertheless be left counting angels. As a result, to get a feel for the issues
that may crop up in developing a local-REST approach (henceforth, LREST) and how it compares with straight JS APIs we'll
start from a related and well-known JS API