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

61–70 of 117 posts

Re: REST Hooks - Stop the polling madness

#61

Post by sopooneo »

Kiro wrote: post #55
joeblau wrote: post #45

Earlier quoted context omitted.

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?

People argue that, with REST, versioning should be done in headers and not the url. Maybe that?

Re: REST Hooks - Stop the polling madness

#62

Post by singlow »

kristopolous wrote: post #57
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!

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.

Re: REST Hooks - Stop the polling madness

#63

Post by steveklabnik »

sopooneo wrote: post #61
Kiro wrote: post #55

Earlier quoted context omitted.

How does it break HATEOAS?

People argue that, with REST, versioning should be done in headers and not the url. Maybe that?

Nooe, HATEOAS is about links. The official-sounding thing that this would violate is the "server should be able to organize its own namespace."

That said, I don't think this actually mandates any URLs. I read that part as just a suggestion for how it could be done.

Re: REST Hooks - Stop the polling madness

#66

Post by sopooneo »

steveklabnik wrote: post #63
sopooneo wrote: post #61

Earlier quoted context omitted.

People argue that, with REST, versioning should be done in headers and not the url. Maybe that?

Nooe, HATEOAS is about links. The official-sounding thing that this would violate is the "server should be able to organize its own namespace." That said, I don't think this actually mandates any URLs. I read that part as just a suggestion for how it could be done.

Does that mean it should be possible to just have the link be "subscription"?

Re: REST Hooks - Stop the polling madness

#67

Post by steveklabnik »

sopooneo wrote: post #66
steveklabnik wrote: post #63

Earlier quoted context omitted.

Nooe, HATEOAS is about links. The official-sounding thing that this would violate is the "server should be able to organize its own namespace." That said, I don't think this actually mandates any URLs. I read that part as just a suggestion for how it could be done.

Does that mean it should be possible to just have the link be "subscription"?

It means that the spec shouldn't specify URIs, and instead publish link relations.

(I'm not saying that I think it should be that way, just elaborating.)

Re: REST Hooks - Stop the polling madness

#68

Post by brian_cooksey »

kristopolous wrote: post #57
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!

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.

Re: REST Hooks - Stop the polling madness

#69

Post by prodigal_erik »

The docs talk about "event types" like contact.update which do not exist in HTTP and require knowing the semantics of a particular group of resources. To truly be RESTful, I would want "please notify me of any PUT, PATCH, or DELETE to this list of URLs, or POST creating a URL that matches this pattern." And if you're going to include a copy of the resource (I don't know what else a payload would be) you need the media type the subscriber expects as if you were doing content negotiation for a GET request from them. Or maybe the payload could just be the current result of a HEAD request so the subscriber can invalidate their caches, and they can send the appropriate GET request(s) when and if they care to.

There should be some standard link relation like so clients have some hint that this is available and where to request it.

I'd also want some way to manage the freshness/load tradeoff, like "please notify me within one hour but no more than every five minutes".

Re: REST Hooks - Stop the polling madness

#70

Post by [deleted] »

kristopolous wrote: post #57
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!

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…

[deleted]
Post reply on HN