[aantix]

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.

[bryanh]

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!

[onli]

So all this is just about the following pattern?

A wants to get updates of B. Instead of polling B for changes, it sends B or C an URL of A and says: POST to this URL the moment something changes on B.

If that's the case, this really gets lost on all the hooks/subscriptions/load-mumbojumbo on this site.

[bryanh]

That is the case! It's actually a hard concept to get across in words (we've found). If you have or see an example that really resonates with you, do let us know (and we're open to pull requests https://github.com/zapier/resthooks :-).

[onli]

I think what is missing is the explanation of a subscription. On the github-page, there is only one sentence in that regard:

> REST Hooks are a lightweight subscription layer on top of your existing REST API.

That is too short. There the explanation is missing, the same way on the website. maybe in better english if mine is broken, but that addition could fix it: "...,thus that instead of having to poll that API regularly, the subscriber is notified with a POST the moment a change occurs."

I'm probably biased, because that is kind of the same way I once tried to explain the concept, but I think it would be clearer that way.

[bryanh]

Thanks! We'll try to work that into the next round of edits!