Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

REST Hooks - Stop the polling madness

resthooks.org

Post reply on HN
Print view View original

81–90 of 117 posts

Re: REST Hooks - Stop the polling madness

#81

Post by jqueryin »

yajoe wrote: post #37
neilk wrote: post #32

Earlier quoted context omitted.

Better. That's practically the only thing that needs to be on the home page. You also need to explain who you are and why you're doing this, too. Right now it looks like you have an interest in selling something but you never explain what it is. It reminds me a lot of those sites which sell some miracle product, and are deliberately very long and vague, and it ends finally with some button to order an ebook or someth…

At the bottom of the page I saw: > An initiative by Zapier 2013. Zapier is a company that makes money off sites having REST endpoints to push and pull data. It looks like Zapier would prefer that more sites have endpoints to accept push, and this marketing effort is a brand-campaign (think Public Service Announcement) to get more people to tailor their products to work with Zapier. That explains why more emphasis was…

As I read through the website, I felt mislead by the title "REST Hooks - Stop the polling madness" in that I believed we were talking directly about reducing something like AJAX long polling for an alternative means of retrieving data from the backend.

Having felt that pain before, and not opting for WebSockets yet, I was hoping for some kind of simple alternative. I have a portion of code that occurs during a registration process that is currently polling the backend for status updates as to the worker queue's progress (it's a lengthy registration with several moving pieces and calls to multiple remote APIs).

Re: REST Hooks - Stop the polling madness

#82

Post by [deleted] »

bryanh wrote: post #26
annnnd wrote: post #8

Am 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. Thanks for the feedback!

[deleted]

Re: REST Hooks - Stop the polling madness

#83

Post by amenod »

bryanh wrote: post #26
annnnd wrote: post #8

Am 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. Thanks for the feedback!

This is definitely better, but what I would expect is a short explanation of what happens to REST requests - why are there fewer of them? Are you caching the responses, serving them to clients (who are still polling, but they are polling you instead of the REST server) and waiting for PUSH request from server to invalidate the cache? Or is this a client-side solution too which allows a client to trigger a REST request only when data is available?

Re: REST Hooks - Stop the polling madness

#84

Post by shortcj »

amenod wrote: post #83
bryanh wrote: post #26

Earlier quoted context omitted.

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. Thanks for the feedback!

This is definitely better, but what I would expect is a short explanation of what happens to REST requests - why are there fewer of them? Are you caching the responses, serving them to clients (who are still polling, but they are polling you instead of the REST server) and waiting for PUSH request from server to invalidate the cache? Or is this a client-side solution too which allows a client to trigger a REST reques…

It would be interesting if browsers could accept HTTP requests.

Re: REST Hooks - Stop the polling madness

#87

Post by dpweb »

Powerful idea, should be made a specification. Simple enough too - what they describe is almost trivial to implement in /* insert your web framework of choice */. You wouldn't even need a library. Handle your HTTP verbs, store subscriber state, and call them out on events. It's nice.

Re: REST Hooks - Stop the polling madness

#88

Post by medius »

brian_cooksey wrote: post #68
kristopolous wrote: post #57

Earlier quoted context omitted.

I have no idea how this solves the fundamental push/pull networking problem. Is a network connection kept open? Is there an assumption that the user has some port open that can be contacted? I see that you somehow reduced your calls, but I don't see how. Please tell me in actual socket level networking terms how this is done; who establishes a connection to what, for what, and for how long? Also how do you deal with…

Server A has events Server B wants to know about. With REST Hooks, Server A provides an API that Server B use to tell Server A "Please POST notifications about those events to this URL". Then Server B keeps a web server listening for requests to that url. There is no persistent connection. As for timeouts, check out http://resthooks.org/docs/retries/ for ideas on how those problems can be solved.

So it's an API to configure webhooks on Server A?

Re: REST Hooks - Stop the polling madness

#89

Post by bryanh »

amenod wrote: post #83
bryanh wrote: post #26

Earlier quoted context omitted.

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. Thanks for the feedback!

This is definitely better, but what I would expect is a short explanation of what happens to REST requests - why are there fewer of them? Are you caching the responses, serving them to clients (who are still polling, but they are polling you instead of the REST server) and waiting for PUSH request from server to invalidate the cache? Or is this a client-side solution too which allows a client to trigger a REST reques…

There is no middle intermediary, its just two servers. For example, Facebook & your app.

Instead of polling `facebook.com/api/posts` every 2/5/15/60 minutes, you'd set up a subscription for Facebook to ping you at `yoursite.com/hook.php`. The subscription would be managed under `facebook.com/api/subscriptions`.

Re: REST Hooks - Stop the polling madness

#90

Post by bryanh »

onli wrote: post #75
bryanh wrote: post #43

Earlier quoted context omitted.

The server itself will just POST a payload to a defined URL. I'm not wildly familiar with the internals of that app or Rails in general, otherwise I'd give more detail!

So all this is just about the following pattern? A wants to get updates of B. Instead of polling B for changes, it sends B or C an URL of A and says: POST to this URL the moment something changes on B. If that's the case, this really gets lost on all the hooks/subscriptions/load-mumbojumbo on this site.

That is the case! It's actually a hard concept to get across in words (we've found). If you have or see an example that really resonates with you, do let us know (and we're open to pull requests https://github.com/zapier/resthooks :-).
Post reply on HN