[johns]

A great way to get webhooks to the client is through some sort of real-time push service. Either homegrown or something like Pusher. You'd have to listen at a webhook endpoint then re-create the event in Pusher, but the client would be simple. Pusher might even support creating the event directly from a webhook, I can't recall.

If you don't want to maintain the webhook listener, create a script on webscript.io to listen and create the Pusher event.

[deckyt]

Nice suggestions. I'll have to give Pusher a try one of these days. I've actually worked with the homegrown approach before, having my client connect to websocket endpoints that subscribe them to a redis channel where real-time updates are published as events occur within the system.

One thing that's often bothered me about that approach is how I've handled both websocket and RESTful HTTP endpoints from a single server. The solution mentioned by OP could go some way to allowing me to move the websocket/push handlers off to a dedicated server. This 'push server' might consume the REST API exposed by my HTTP server to set up webhooks. It could then forward information coming in on the hooks to the client, using some push mechanism, be that websockets, Pusher, whatever.

Thanks for your reply :)