Developers,
Which do you prefer: webhooks or websocket? I don't have a ton of experience with websockets. In a conversation with a company about how they can best expose an API for me to use, and they asked if I would prefer webhooks or websockets. What would you prefer for developing an HE driver/app, i.e., what would you tell them?
Is it a continuous data stream (or 2-way communication) or is it discrete discontinuous information?
For example, MQTT and webhooks work well when sending data from the OwnTracks client on my phone to my MQTT server or to Hubitat. There are updates every 5-10 minutes, so there isn’t much overhead in making a new connection each time.
A single websocket, left open, works well to receive data from my weather station, where there are multiple updates in a minute. Leaving the connection open removes the overhead of making a new connection for each update.
4 Likes
Either could work, and both have some advantages and disadvantages. A webhook is pretty simple since it doesn't require a persistent connection; a websocket does, and so some care will need to be taken to connect when needed, reconnect if dropped (perhaps not too aggressively?), and similar. But, if there is lots of back-and-forth, the websocket is likely to be more efficient--both in general but also because, at least early on, some people reported some inefficiencies with the HTTP APIs on the hub (can't remember if it was actually a memory leak or just a guess, and I don't know if it was the all HTTP methods or if the newer async ones are better, though they are better for most cases in general for other reasons).
One consideration is that if the API is sending information to a hub and you're using webhooks instead of a websocket, you might need an app in addition to a driver; a driver can receive traffic on port 39501 if the device can be configured to do that. But for arbitrary endpoints on standard HTTP/HTTPS ports, you'll need an app with mappings/endpoints defined (the app could then pass it on to, say, a child/component device--a driver just can't do OAuth directly). But, again, if traffic is local and you can specify the port, this isn't necessary; it's also not necessary for websockets (in fact, only drivers can use them directly). Sometimes having an app makes configuration easier for users than just a driver page if that's a concern, and that's something you could do either way--just a matter of what work gets done where.
If the API is cloud and not local, the vendor may have some preferences, and I'd be surprised if they like the idea of a websocket. 
But from the hub side, a you could certainly handle either, with it just with some differences as how how you send and receive things.
2 Likes
I think it would be discrete discontinuous info to provide notifications of events that occur during 3D printing, e.g., temp setpoint reached, print started, print failure event, print completed, temp cooldown, etc. So sounds like webhooks might be more fitting?
1 Like
Gotcha. The API would be local.
1 Like
That makes a WS as attractive as a webhook.
websocket is also useful if you need a bi-directional communication mechanism in the same channel.
2 Likes
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
