Re: Devices as Virtual Web Services

Hi Kenton,

On Jan 25, 2010, at 21:24 , Kenton Varda wrote:
> I don't think anyone debates the fact that writing code against a REST service will not be as convenient as writing code against a Javascript API.  However, I think the other advantages greatly outweigh this inconvenience.

I think that these advantages are rather elusive in a number of cases. Security has been mentioned as one, but I have yet to see someone make the case for it beyond merely mentioning it and rumours that DAP "doesn't understand security".

As stated elsewhere, I can certainly see the potential value in exposing some services in the same way locally and remotely, and a RESTful approach is an elegant way to achieve that. But that only concerns some of the APIs on DAP's plate IMHO, and I don't see that the advantages "far outweigh" the inconveniences.

> I think the purpose of the standards process is to facilitate interoperability, *not* to make developers' lives easy.

Given a choice between two solutions of equal interoperability levels and functionality, we should *definitely* go with the one that makes developers' lives easier. As much as I love some of the libraries out there, I really don't want to be forced to use one — tools won't save us.

> As for the goal of interoperability, I think that goal is much better served by basing the standards on REST.  HTTP is already a standard protocol with standard access control mechanisms, and its use is well-understood.  By exposing devices as REST services, we make the problem of implementing a new device equivalent to the problem of writing a new web service, for which many tools and much expertise already exist.  Exposing a new device may be as easy as providing a local web server implementing it, perhaps with no browser changes needed at all.  Providing access to non-local devices and writing non-browser-based software that accesses devices both become trivial even though those were not our intentions.  I think all of this means that a standard based on REST is likely to get much wider use than a standard based on Javascript APIs.  As a nice bonus, creating the standard itself would be much less work.

Several notes:

  - exposing APIs inside browsers using Javascript isn't exactly new and unknown. In fact, it predates REST (as an acronym).
  - the only way in which you get local services exposed with no browser change at all is if you put an HTTP service on localhost, somehow solve the security issues in accessing it, etc. no?
  - Less work how? We'd still have to describe operations, exchange format, error conditions (of which there would be more), etc.

--
Robin Berjon
  robineko — hired gun, higher standards
  http://robineko.com/

Received on Wednesday, 27 January 2010 11:12:36 UTC