[tvcontrol-api] API surface and REST-based approach

tidoust has just created a new issue for 
https://github.com/w3c/tvcontrol-api:

== API surface and REST-based approach ==
The TAG makes the following comment that touches on (lengthy) 
discussions the TV Control WG had on whether the API could better be 
formulated as HTTP request/response exchanges:

[[
We're wondering if new APIs in this style might be phrased in a way 
that has a smaller API surface area, e.g., HTTP request/response or 
Service Worker Foreign Fetch 
(https://developers.google.com/web/updates/2016/09/foreign-fetch) 

May be possible to model many of the APIs here as locally-provided 
HTTP services; e.g. this: 
https://w3c.github.io/tvapi/spec/#tvsource-interface 

Might instead be modeled as a set of requests and responses via 
`fetch()`:
```js
fetch("https://example.com/services/v1/channels")
   .then((resp) => {
      resp.json().then((channels) => {
         console.log(channels);
      });
   });
```

Open issues with a design like this involve a standard location for 
such an RPC interface and a format for the returned data. This seems 
like a good thing for a TV control interface spec to define, perhaps 
using a system like [JSON Schema](http://json-schema.org/)

It's also unclear how the event-sending side of this might work, but 
we're confident that can be overcome in the Foreign Fetch model, 
perhaps by allowing FF responses to contain `MessagePort` objects.
]]

Please view or discuss this issue at 
https://github.com/w3c/tvcontrol-api/issues/24 using your GitHub 
account

Received on Friday, 4 November 2016 16:18:03 UTC