Live data from Hacker News

REST Hooks - Stop the polling madness

resthooks.org

51–60 of 117 posts

Re: REST Hooks - Stop the polling madness

#51
I hate to be THAT guy but someone was going to say it so it may as well be me :)

This is a collection of patterns, right? Well why not make this really REST and rather than list a bunch of URL templates provide REL types for each of these like so:

REL subscriptions-list

Re: REST Hooks - Stop the polling madness

#52
Curious if anybody can answer a question for me. I've recently started building some apps with MeteorJS, and am having loads of fun with it. At first I'd been a bit suspicious of its magic pixie dust -- seemed too good to be true -- but so far it's done everything it promised, and has allowed me to focus on developing the parts of the app I care about. After checking briefly to see that my data syncing was genuinely low-latency and low-bandwith (which under every test I've subjected it to, it appears to be), I've pretty much forgotten about this level of engineering and have focused on bigger-picture stuff.

Which brings me to the question: should I care about something like REST Hooks? Is it a mistake to become complacent and assume that the lower-level infrastructure will Just Work? Or can MeteorJS (and presumably other high-level frameworks) be trusted to handle this kind of stuff in a way that makes it safe for me to forget about it?

Just curious what the esteemed HN denizens think about this, as I'm sure there are some strong and reasonably well-informed opinions out there...

Re: REST Hooks - Stop the polling madness

#53
post #52

Curious if anybody can answer a question for me. I've recently started building some apps with MeteorJS, and am having loads of fun with it. At first I'd been a bit suspicious of its magic pixie dust -- seemed too good to be true -- but so far it's done everything it promised, and has allowed me to focus on developing the parts of the app I care about. After checking briefly to see that my data syncing was genuinely…

I think, if anything, Meteor proves it's possible that it can be the responsibility of the framework, not the developer.

Re: REST Hooks - Stop the polling madness

#54
I hate to be THAT guy but someone was going to say it so it may as well be me :)

This is a collection of patterns, right? Well why not make this really REST and rather than list a bunch of URL templates provide REL types for each of these like so:

REL subscriptions-list -> GET subscription-create -> POST subscription-read -> GET subscription-update -> PUT subscription-destroy -> DELETE

Now it doesn't matter what the URL structure is, I can pull the elements from the page and be TOLD the URL, rather than follow a URL template. That way, this doesnt rely on out of band knowledge i.e this web page and its (poor) description.

Re: REST Hooks - Stop the polling madness

#55
post #45
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.

How does it break HATEOAS?

Re: REST Hooks - Stop the polling madness

#56
post #6
post #4

I don't really understand what this is. Is this an attempt at a formalization of webhooks + JSON?

Same here - I keep coming back to "are they just talking about webhooks? or are they also talking about some kind of persistent http streaming api?" I'm thinking these are just Webhooks, but the REST part is throwing me off because I think of it more as a consumption concept (consuming resources, etc). Update: Found this, which I think explained it best: "REST Hooks itself is not a specification, it is a collection o…

Oh, ok. That makes sense. I implemented that for Emma a few years ago but I don't know if I made it up or saw it somewhere else first. Probably the latter.

Re: REST Hooks - Stop the polling madness

#57
post #26
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!

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 disconnects, timeouts, and missed realtime data.

Re: REST Hooks - Stop the polling madness

#59
post #40

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

Its true, thats a large part of the issue. If you put so many links to /doc om your homepage, well...

Even then, this page (/docs) barely says anything. Almost anything can be 'compliant,' because there's almost nothing to say. I really think some rigor would help a lot. I can appreciate not wanting to get into full RFC2119 right away, but you need some amount of description.

PuSH is not limited to a XML/ATOM, and companies like SuperFeedr use PuSH with JSON.

In fact, I'm pretty sure PUSH is 98% of a webhooks implemenation.

I didnt understand that the numbers were from anything real, my mistake and apologies.

Re: REST Hooks - Stop the polling madness

#60
post #39
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…

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.

Ditto.
Post reply on HN