Subscriptions with WebSockets

[benfrancis]

As a web app developer I want to subscribe to events and property changes of Things hosted by the gateway using WebSockets so that I don't have to keep polling the server.

[benfrancis]

HTTP does not have a pub/sub mechanism and relies on polling, long-polling or webhooks to be notified of changes of state of resources on the server.

Our current draft of the Web Thing API suggests a way of subscribing to events and property changes by upgrading an HTTP GET request on a property or event resource to a WebSocket connection so that the server can push changes back to the client.

In #27 we have a similar requirement to subscribe to a list of new devices as the pairing process happens. This is the first time we're implementing this type of mechanism.

The current proposal in the Web Thing API spec could result in multiple open websockets per client. For a complex UI which needs to be notified of many different types of state change on multiple Things this could reach quite a large number, which might not scale well.

We need to think about the best way to observe changes of Things using web technologies, ideally without having to poll the server.

The CoAP protocol has a proposed observe extension for this purpose, but HTTP doesn't have an equivalent.

The Web Thing Model proposal uses a subscription mechanism which can use webhooks or websockets and creates subscription resources on the server which can be DELETEd to cancel a subscription. It appears that an implementation of this specification would also result in multiple websockets per client, but the reference implementation does not appear to fully implement that part of the spec.

The current draft of the W3C's Web Thing Description spec has the concept of Events and notes that CoAP has a native mechanism for subscribing to events, but suggests that HTTP would have to poll the server.

[benfrancis]

I'm starting to wonder whether you should just open one WebSocket per Thing...

GET /things/myThing
Upgrade: websocket
...

With the option of subscribing to all things...

GET /things
Upgrade: websocket
...

Or a subset of things

GET /things/?type=onOffSwitch
Upgrade: websocket
...

If you're subscribing to a whole Thing rather than just a single property, the challenge is then how to do that without having to invent a whole pub/sub sub-protocol to use over WebSockets and keep it feeling like a natural extension of REST (like CoAP has), rather than a completely separate API.

For example, when a property changes would you send the whole Thing description including property values down the WebSocket, or some sort of "property changed" message?

[benfrancis]

We have the basics of this working now.