Hacker News Reader

Comment by steveklabnik | Hacker News Reader

> 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 reads to me as "everyone is going to have a slightly incompatible implementation. One library wont be good enough, I'll need to write a new one per site that uses this."

Furthermore, what about PubSubHubbub?

Finally, polling is great: Ive found few situations where it doesn't work well, people just tend to only do the most basic of implementations and blame polling. See http://roy.gbiv.com/untangled/2008/paper-tigers-and-hidden-d... for a really interesting example.

EDIT: numbers were real, added a supporting link

View on HN

GitHub implements the PSHB subscription API. It's fine, but doesn't really fit in well with the rest of our JSON API. For instance, parameters are sent over as form encoded values like "hub.mode".

http://developer.github.com/v3/repos/hooks/#pubsubhubbub

We also have a regular JSON endpoint for our hooks resource (which is essentially a subscription API).

Let's make it better :) The PubSubHubbub mailing list is still open and would welcome your comments on how to make things better!

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 callback: at this point in time any flavor will do. We have no doubt that a formal spec will pop up someday (and that would make us very happy!).

> Furthermore, what about PubSubHubbub?

PubSubHubbub always seemed a little heavy and was a departure from APIs that weren't XML/ATOM based (meaning most JSON API providers wouldn't touch it). Not saying I agree with it, but that is the feedback we got.

> Finally, polling is great for 99% of use cases (I can make up statistics, too)

We posted the numbers driving our stats on the homepage. They are not made up and come straight for our Elasticsearch cluster. I'm happy to elaborate on them!

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.

Reply on news.ycombinator.com