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

91–100 of 117 posts

Re: REST Hooks - Stop the polling madness

#91

Post by mmgutz »

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…

Agree with you. If the audience is developers, give it to us in black in white instead of some new jargon and marketing blah.

I looked through several pages (waste of time) and I still can't figure out how this is real time without websockets, polling, server side events. No way I would use this service if they don't know who their audience is.

Re: REST Hooks - Stop the polling madness

#92

Post by onli »

bryanh wrote: post #90
onli wrote: post #75

Earlier quoted context omitted.

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 :-).

I think what is missing is the explanation of a subscription. On the github-page, there is only one sentence in that regard:

> REST Hooks are a lightweight subscription layer on top of your existing REST API.

That is too short. There the explanation is missing, the same way on the website. maybe in better english if mine is broken, but that addition could fix it: "...,thus that instead of having to poll that API regularly, the subscriber is notified with a POST the moment a change occurs."

I'm probably biased, because that is kind of the same way I once tried to explain the concept, but I think it would be clearer that way.

Re: REST Hooks - Stop the polling madness

#93

Post by bryanh »

singlow wrote: post #62
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…

I think they are just suggesting that services which are being polled frequently instead implement a rest-like subscription service which would accept an endpoint and then push the data to all of the subscribed endpoints when it changes. In many cases it is more work from the developers of those services but would reduce their bandwidth and server load immensely.

This is a very good summary.

Re: REST Hooks - Stop the polling madness

#94

Post by bryanh »

onli wrote: post #92
bryanh wrote: post #90

Earlier quoted context omitted.

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 :-).

I think what is missing is the explanation of a subscription. On the github-page, there is only one sentence in that regard: > REST Hooks are a lightweight subscription layer on top of your existing REST API. That is too short. There the explanation is missing, the same way on the website. maybe in better english if mine is broken, but that addition could fix it: "...,thus that instead of having to poll that API regu…

Thanks! We'll try to work that into the next round of edits!

Re: REST Hooks - Stop the polling madness

#95

Post by acjohnson55 »

singlow wrote: post #62
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…

I think they are just suggesting that services which are being polled frequently instead implement a rest-like subscription service which would accept an endpoint and then push the data to all of the subscribed endpoints when it changes. In many cases it is more work from the developers of those services but would reduce their bandwidth and server load immensely.

Ohhh, so it's really a server-side technology to better consume third-party APIs. For whatever reason, this wasn't at all obvious to me. I had initially assumed that this was technology between client and server sides of a single-page application.

Re: REST Hooks - Stop the polling madness

#96

Post by julien »

technoweenie wrote: post #74
steveklabnik wrote: post #33

> REST Hooks itself is not a specification, it is a collection of patterns that treat webhooks like subscriptions. Bummer. No matter if you like it or not, a collection of patterns with a name _is_ a specification, just possibly a poorly defined one. See the confusion in this thread. If it were a link to a spec, nobody would be confused. > Skip the pedantic arguments about standards and implementation details This re…

GitHub implements the PSHB subscription API. It's fine, but doesn't really fit in well with the rest of our JSON API. For instance, parameters are sent over as form encoded values like "hub.mode". http://developer.github.com/v3/repos/hooks/#pubsubhubbub We also have a regular JSON endpoint for our hooks resource (which is essentially a subscription API).

Let's make it better :) The PubSubHubbub mailing list is still open and would welcome your comments on how to make things better!

Re: REST Hooks - Stop the polling madness

#98

Post by nilliams »

mmgutz wrote: post #91
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…

Agree with you. If the audience is developers, give it to us in black in white instead of some new jargon and marketing blah. I looked through several pages (waste of time) and I still can't figure out how this is real time without websockets, polling, server side events. No way I would use this service if they don't know who their audience is.

Yep the missing part of the description is 'server-to-server', or 'client-with-a-listen-port (i.e. not a browser) to server'.

Unfortunately a lot of us developers see the term REST API and think a-ha, this is something I can consume in my browser. This isn't that, so confusion ensues.

Re: REST Hooks - Stop the polling madness

#99

Post by johns »

bryanh wrote: post #80
lojack wrote: post #79

While the paradigm of having a webhook makes more sense, I personally hate working with them. I've yet to see a graceful way of handling local development that doesn't involve localtunnel (or some alternative) and constantly having to un-register and re-register endpoints every time localtunnel gives you a new hostname. I understand the point and would prefer working with them if there was just a good way to handle l…

This is a great point, is there a better way to do local dev with webhooks? I always used localtunnel which is great it not perfect.

Some other options here: http://john-sheehan.com/blog/a-survey-of-the-localhost-proxy...

I personally think you should be using one that gives you permanent URLs (ngrok or Passageway) but that also keeps a log when you're client is disconnected. I'm pretty sure only our Passageway does that.

Re: REST Hooks - Stop the polling madness

#100

Post by johns »

bialecki wrote: post #78

If for some reason you can't or don't want to implement webhooks, at least make sure you the GET endpoint for any object has a query param that supports fetching the most recently updated or created objects and supports pagination. It sounds trivial, but you'd be surprised how many APIs don't support one or both of those features. When you're writing an API it might seem unnecessary to start (after all, who could eve…

You can send a webhook to localhost, just in a roundabout way using one of the local tunneling solutions: http://john-sheehan.com/blog/a-survey-of-the-localhost-proxy...

Great points though.

Post reply on HN