WebHooks as alternative to WebSockets?

(Martin Giger) #1

This is a purely educational question and not a request for protocol expansion.

Here in Switzerland there’s a company, myStrom, that makes smart home devices with very simple web APIs built in. For their buttons they use extremely primitive web hooks to deliver the events: https://mystrom.ch/wp-content/uploads/REST_API_WBS-1.txt

This got me thinking, that there may be devices that can’t keep a websocket connection, or possibly multiple websocket connections opened and implementing web hooks would be much simpler for them. It’d allow the device to hibernate in between samples, for example.

The w3c has recently standardized a protocol to establish web hook subscriptions: https://www.w3.org/TR/websub/

Would it make sense to allow things to provide web hooks instead of a socket for updates?

(Rzr) #2

Well It would say it depends on the refresh rate, try to implement it and then we can compare performance.

(Martin Giger) #3

This is mainly for a device side, which concerns the resources of the device, and open sockets do take up processing power, whereas webhooks don’t have any long-running sockets that stay open. So the performance will surely be very different for the device.

The “refresh rate” of data sent by webhooks is in the end under control by the device, so the device could even scale the refresh rate to the subscriber count, which would allow devices to server more subscribers.

At the same time I doubt that many devices will have more than maybe two or three subscribers, unless they are public devices, available on the internet (open sensor networks and such, if they ever adapt the WoT). In that case it may be very interesting for them to have webhooks.
However that then also introduces some complications in the negotiation, since the gateway has to find out, what kind of address it’d have to make the subscription for, so potentially it’d only work when the gateway has a tunnel or a public port forward set up that it is aware of.

(Martin Giger) #4

I had previously linked to the wrong webhook spec because it’s not called webhooks but websub: https://www.w3.org/TR/websub/