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

41–50 of 117 posts

Re: REST Hooks - Stop the polling madness

#41

Post by bryanh »

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…

Bingo!

Re: REST Hooks - Stop the polling madness

#42

Post by aantix »

bryanh wrote: post #3

We also wrote a quick drop-in Django application [0] (that plugs right into TastyPie if you have an API built on it) . We also have a sample CRM with a live API running [1]. Our friends at NetEngine wrote a sample Rails app [2], and our very own James wrote an awesome Node.js Sails app [3]. [0] https://github.com/zapier/django-rest-hooks [1] http://demo.resthooks.org/ [2] https://github.com/net-engine/resthooks [3] h…

Still scratching my head on the Ruby "reference" implementation. When I subscribe resource_subscriptions, who is receiving the update notification? Is the client side js code getting a push? Is the resource_subscriptions a long-polling endpoint? Not very clear at all.

Re: REST Hooks - Stop the polling madness

#43

Post by bryanh »

aantix wrote: post #42
bryanh wrote: post #3

We also wrote a quick drop-in Django application [0] (that plugs right into TastyPie if you have an API built on it) . We also have a sample CRM with a live API running [1]. Our friends at NetEngine wrote a sample Rails app [2], and our very own James wrote an awesome Node.js Sails app [3]. [0] https://github.com/zapier/django-rest-hooks [1] http://demo.resthooks.org/ [2] https://github.com/net-engine/resthooks [3] h…

Still scratching my head on the Ruby "reference" implementation. When I subscribe resource_subscriptions, who is receiving the update notification? Is the client side js code getting a push? Is the resource_subscriptions a long-polling endpoint? Not very clear at all.

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!

Re: REST Hooks - Stop the polling madness

#45

Post by joeblau »

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…

You are not the only one. I read though it, clicked around, looked at the demos, thought about bookmarking it, got to the documentation page and saw this `/api/v1/subscription/`, thought That breaks HATEOAS then left.

I'm sure if I put more time into trying to understand what is going on I could figure it out, but to me, the message isn't that clear.

Re: REST Hooks - Stop the polling madness

#46

Post by bryanh »

lvh wrote: post #36

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 fact…

That is a good point. What kills us the most is the latency on network IO when polling.

Re: REST Hooks - Stop the polling madness

#47

Post by brian_cooksey »

hcho wrote: post #18

Doesn't this assume that the API will only be used from a module living under a URL? Most REST apis these days seem to be consumed form client side.

The focus is on server-server communication. A client like a web browser would need to use a different approach to get notifications, but there are options in that space besides polling.

Re: REST Hooks - Stop the polling madness

#49

Post by tkellogg »

This isn't impressive. [MQTT][1] is a much better protocol, and an open standard. It's a pub/sub that runs over TCP with variants that run over UDP & TLS. There's only a 2+ byte overhead, so it's very light. It's ideal for mobile devices because it has a QoS system built-in, so the developer doesn't have to think through the problem of missing messages where cell service is sub-optimal. MQTT is even resource-based, so it fits well with REST. I wish more people would start using MQTT instead of these crazy hacks like REST Hooks.

[1]: http://mqtt.org/

Post reply on HN