Are there patterns for client side JavaScript to be notified of changes to REST resources? I don't believe this particular pattern applies if I understand correctly as it needs a URL to notify.
REST Hooks - Stop the polling madness
21–30 of 117 posts
Re: REST Hooks - Stop the polling madness
#22> On average, 98.5% of polls are wasted Erm. Is there a source for that?
83% of statistics are made up on the spot.
Re: REST Hooks - Stop the polling madness
#23It is awfully difficult to get a technical TL;DR version from a website, whose target audience is programmers. I think explaining what this does concisely and technically, preferably on the front page with code examples etc would be really useful.
Re: REST Hooks - Stop the polling madness
#24Are there patterns for client side JavaScript to be notified of changes to REST resources? I don't believe this particular pattern applies if I understand correctly as it needs a URL to notify.
I think you'd have to have your server receive the hook, and then notify the client side using websockets/long polling etc. Pusher makes that really easy.
Re: REST Hooks - Stop the polling madness
#25In addition to webhooks, using a websocket connection to listen for streaming updates is a great way to eliminate polling.
They are also easier to use and much more straightforward than hooks. And if you use something like Socket.IO the adoption of WS is irrelevant.
Re: REST Hooks - Stop the polling madness
#26Am I the only one who has trouble sifting through all this marketing? Even "read more" link leads to an article where half of the text promises what will be covered and another half talks about some subscriptions and how they are managed (they might have been mentioned in the first half, I agree - and I also read text only twice). If someone has a better understanding of how this works, I would appreciate a TL;DR ver…
We are pushing some copy updates to the homepage, most of the technical details were in docs. TL;DR coming to the homepage soon, but the gist is:
REST Hooks itself is not a specification, it is a collection of patterns that
treat webhooks like subscriptions. These subscriptions are manipulated via a
REST API just like any other resource. That's it. Really.
Re: REST Hooks - Stop the polling madness
#27This sounds pretty much like the polyfill Socket.IO/SockJS do to create a socket atop polling-based transports.
Re: REST Hooks - Stop the polling madness
#28Has anyone use PubSubHubbub ( http://en.wikipedia.org/wiki/PubSubHubbub ) for this pattern in the past? For straight subscriptions, it's always been compelling to think of the use cases being covered by PSHB and RSS.
It is pretty fantastic.
Re: REST Hooks - Stop the polling madness
#29[deleted]
Re: REST Hooks - Stop the polling madness
#30> On average, 98.5% of polls are wasted Erm. Is there a source for that?
A bit further down the page, they cite Zapier
"Over a representative time period, Zapier polled for changes 30 million times but only took action on 460,000 of those polls (1.5% efficient)."