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

31–40 of 117 posts

Re: REST Hooks - Stop the polling madness

#31

Post by carrja99 »

mcantrell wrote: post #11
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…

Here's my basic understanding of it: This sounds like webhooks, but they have a set payload, so that the server that is sent the webhook just calls the rest endpoint it is given in the payload.

Basically we're taking webhooks and adding a RESTful subscription layer to it. This way users don't have to go copy and past webhook urls into other applications... the applications they use automatically create and destroy the subscriptions for them.

Re: REST Hooks - Stop the polling madness

#32

Post by neilk »

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!

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 something.

Re: REST Hooks - Stop the polling madness

#33

Post by steveklabnik »

> 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 reads to me as "everyone is going to have a slightly incompatible implementation. One library wont be good enough, I'll need to write a new one per site that uses this."

Furthermore, what about PubSubHubbub?

Finally, polling is great: Ive found few situations where it doesn't work well, people just tend to only do the most basic of implementations and blame polling. See http://roy.gbiv.com/untangled/2008/paper-tigers-and-hidden-d... for a really interesting example.

EDIT: numbers were real, added a supporting link

Re: REST Hooks - Stop the polling madness

#34

Post by Hovertruck »

andrewjshults wrote: post #30
Hovertruck wrote: post #19

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

Ah, I must've missed that. Thanks!

Re: REST Hooks - Stop the polling madness

#35

Post by julien »

rcsorensen wrote: post #17

Has 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.

So, PubSubHubbub is not linked with RSS anymore and works with any type of data format, including JSON obviously :)

The quick win of PubSubHubbub compared to Resthook is that it has a 'security' mechanism in it, which means that the subscriber can be 100% sure that the service sending the notification is not someone impersonating it.

Aside from this, I feel like PubSubHubbub and Reshook solve the same problem: programatically setting up webhooks.

Re: REST Hooks - Stop the polling madness

#36

Post by lvh »

I don't agree with this part:

> In other words, if everyone implemented REST Hooks, server load for both the sender and receiver could be reduced by 66x.

No, the number of requests could be reduced by a factor of 66. I'm not saying that's not impressive, I'm saying that the polling requests that ended up resulting in no action are cheaper than actionable requests, so, server load will go down by much less than a factor of 66x. The amount of work is the same, just busywork is less.

Re: REST Hooks - Stop the polling madness

#37

Post by yajoe »

neilk wrote: post #32
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!

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 put on marketing, etc. The primary audience is not developers but PHBs and PMs to have sound bytes to parrot to developers.

(I'm not cynical, I work in advertising, most of my products already have 'REST hooks'...)

Re: REST Hooks - Stop the polling madness

#38

Post by spdy »

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…

Same for me i miss the How? part.

And i got oversold on an idea that sounds good but i have no clue how it works.

http://en.wikipedia.org/wiki/Webhook

Re: REST Hooks - Stop the polling madness

#39

Post by bryanh »

neilk wrote: post #32
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!

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…

Good point. For us (Zapier), we just waste a lot of time and resources polling. We talked to some of the SaaS services we integrate with and it is the same on their side as well. That is our motivation.

Re: REST Hooks - Stop the polling madness

#40

Post by bryanh »

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…

Hey Steve!

> See the confusion in this thread. If it were a link to a spec, nobody would be confused.

We definitely had a little confusion in the thread, I think that was mostly because we put too much marketing on the homepage for this audience, but the absence of a proper spec could have definitely contributed. We're correcting some of this.

This is all about adoption of some sort of subscription-based HTTP callback: at this point in time any flavor will do. We have no doubt that a formal spec will pop up someday (and that would make us very happy!).

> Furthermore, what about PubSubHubbub?

PubSubHubbub always seemed a little heavy and was a departure from APIs that weren't XML/ATOM based (meaning most JSON API providers wouldn't touch it). Not saying I agree with it, but that is the feedback we got.

> Finally, polling is great for 99% of use cases (I can make up statistics, too)

We posted the numbers driving our stats on the homepage. They are not made up and come straight for our Elasticsearch cluster. I'm happy to elaborate on them!

Post reply on HN