[kristopolous]

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.

[singlow]

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.

[acjohnson55]

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.

[kristopolous]

As did I. I've built these systems (socket-like systems that work efficiently across browser in diverse environments). And if you think you can just get that right the first time, then either you have the hacking skills of which I have never seen or you are (more likely) wrong.

But this thing here they are talking about is something I've been doing for a long time. I didn't think about making a brochure site for it though.

Just follow the principle of making the parts as dumb as possible. They should be the stupidest simplest things ever. Sometimes you can't get to this model on the first try, and that's ok. But the closer you get to it, the better the product becomes. I swear this is true and part of the soul of the machine's ghost.

If you can't make things laterally connect this way, then make them vertically stack this way and then laterally connect this way. But don't obfuscate the objective.

[dmak]

Thats what I thought too.

[bryanh]

This is a very good summary.

[brian_cooksey]

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.

[medius]

So it's an API to configure webhooks on Server A?

[unclebucknasty]

I think it's more of an API to allow Server B to register its interest in receiving notifications from Server A.

Of course, Server A must "speak Rest Hook" in order to enable that, so in a manner of speaking I guess it is a way to configure Webhooks on Server A.

But, it basically exposes a common interface for Server A and Server B to establish Webhooks. Server A can tell Server B which notification subscriptions are available (i.e. for which events), and Server B can then choose to subscribe, providing the callback URL for the Webhook.