Re: Why aren't most devices virtual web services?

Hello,

Reviewing both these examples, and the ones that Doug gave yesterday, I realize that I'm not sure if we all have the same understanding of Mark's original email. 

I'll try to check that by offering my understanding:

We are designing Javascript APIs here. Those APIs involve making Javascript calls. 

As I described in my paper for the TAG, you could provide the same functionality by running a Web server on the device and making RESTful calls to that Web server, getting back HTTP responses, as if the Web server were running on "some server in the cloud" (which it is, of course, it's just that server may not be available via the DNS, it may not be available due to the battery being dead, etc. etc.)

If you think of these things as being "offerable" as Web services, you will try to design them that way, yes - you might assign "virtual" URIs to the method calls or objects. You might implement the method calls in REST style, with a "uniform interface" such as GET, POST, PUT, DELETE. You might use standard methods of securing RESTful services, like OAuth, and CORS/UMP. You might define some equivalence or transformation between a Javascript object literal and some XML form

However, would you really want to standardize the "bare" interfaces for how to do that, or would you want to simply keep designing good Javascript APIs, but all the while thinking of them also as potential RESTful Web services in which case you can see how to apply things like OAuth and other mechanisms which already existing, rather than designing new ones?

My guess is the latter is what we want - or at least, that is what I understood Mark to mean, and certainly which is the part I am agreeing with.

As Tyler suggested, I'm not sure that you would want to standardize actual URIs (unless they are simply _identifiers_ and not also locators), or even assume XHR as part of the underlying implementation. 

I simply think this is about designing APIs in a way that considers the architecture within which those APIs operate to be exactly the same as the existing Web architecture, and to use those architectural principles in designing Javascript APIs. And in some cases, to describe the equivalence. 

Did I get this right?

Regards,

- johnk

On Jan 14, 2010, at 9:39 AM, Robin Berjon wrote:

> On Jan 14, 2010, at 10:56 , Ilkka Oksanen wrote:
>> Robin Berjon wrote:
>>> Beyond that, a (secondary) worry is the maturity of paraphernalia
>>> such as JSON Schema and JSONpath that we could want to use here. But
>>> that's a bridge we can cross any number of ways.
>> 
>> Date objects in parameters or return values can be especially tricky to serialize in virtual web server approach. I'm not sure if for example JSON has yet proper support for Dates. Dates will be part of the API at least in Calendar.
> 
> Right, that's part of my reluctance.
> 
>> In general I'm bit worried how much overhead XHR processing can cause to developers. Assuming I write a simple script that needs Device APIs just to read system's temperature. Are the options to either write a parser myself to remove the transport encoding or to rely on some convenience library that does the decoding? Both options potentially increase script size considerably.
> 
> That is certainly a consideration:
> 
>  // sync
>  alert("Temp: " + navigator.service.system.temperature);
> or
>  // async
>  navigator.service.system.getTemperature(function (t) { alert("Temp: " + t); });
> 
> versus
> 
>  // sync
>  var req = new XMLHttpRequest();
>  req.open("GET", "service://w3c/dap/system/temperature", false);
>  req.send();
>  alert("Temp: " + JSON.parse(req.responseText).temperature);
> or
>  // async
>  var req = new XMLHttpRequest();
>  req.open("GET", "service://w3c/dap/system/temperature");
>  req.onreadystatechange = function () {
>    if (req.readyState == 4) alert("Temp: " + JSON.parse(req.responseText).temperature);
>  }
>  req.send();
> 
> is pretty much a hands-down win for the first. Of course, there are counter-arguments:
> 
>  - more complex examples will be less different, meaning that related advantages can compensate
>  - bare-metal XHR is rare:
> 
>  // sync
>  $.ajax({
>          dataType: "json",
>          src:      "service://w3c/dap/system/temperature",
>          success:  function (data) { alert("Temp: " + data.temperature); }
>  });
>  // async
>  $.getJSON("service://w3c/dap/system/temperature", function (data) { alert("Temp: " + data.temperature); });
> 
> I'm working on more complex examples to investigate.
> 
> --
> Robin Berjon
>  robineko — hired gun, higher standards
>  http://robineko.com/
> 
> 
> 
> 
>

Received on Thursday, 14 January 2010 15:01:53 UTC