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

On Thu, Jan 14, 2010 at 12:36 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Thu, 14 Jan 2010, John Kemp wrote:
> > On Jan 14, 2010, at 3:00 PM, Ian Hickson wrote:
> > > On Thu, 14 Jan 2010, John Kemp wrote:
> > >>
> > >> We are designing Javascript APIs here. Those APIs involve making
> > >> Javascript calls.
> > >
> > > Is this a requirement? If so, why? It seems like if it makes more
> > > sense to expose something as a RESTful API exposed with a custom
> > > scheme handled natively by the UA, then we should do that, rather than
> > > expose things as a JavaScript API.
> >
> > I think what likely makes most sense is what Kenton suggested earlier -
> > a WebIDL binding for RESTful services. That way we should get
> > equivalence between the JS API and the RESTful model without having to
> > specify entirely separate ways (or a new way) of doing things.
>
> Would that mean the API was exposed to users twice? If so, I think it's a
> bad idea -- it would mean two implementations in browsers, and thus twice
> the number of bugs.
>

What I was imagining is that UAs would provide a function like:
  urlToObject(url, interface);

"interface" would be a (URL to a?) definition of the interface, perhaps in
WebIDL or maybe in some equivalent language.  "url" points to the RESTful
API representing a resource implementing this interface.  urlToObject()
returns an object implementing the WebIDL interface in terms of the RESTful
interface.  We then define some standard for this mapping.

For the record, I personally don't have any problem with only providing the
REST API with no automatic conversion to something more friendly.  But if
some people are worried that using XHR directly is too much of a pain -- and
making clients download helper libraries is too expensive -- then maybe a
standard urlToObject() would solve their problem.