Web Hooks at Hackers

[Jeff Lindsay]

I gave my Web Hooks talk at the Hackers conference. It was a small
crowd, but a pretty influential one. It included Ward Cunningham,
Tantek Çelik, Cal Henderson, Leah Culver, Joshua Schachter, and
others.

Cal seemed to like the idea, especially long-term. He did point out
it's more work since it requires persistent state maintenance for each
user as opposed to just rendering a single page feed for everybody.
Joshua pointed out nearly half (sounds like a gross approximation) of
del.icio.us traffic was 304 Not Modified, which is why he's strongly
in the web hooks camp.

Tantek pointed out popular feeds are a bad example to sell the idea of
web hooks (I agree), but in the context of Flickr, there are
*personalized* feeds (such as comment streams) that are much better
suited to web hooks. And are in fact cleaner because the
authentication step isn't required.

There was a lot of discussion about the core mechanic, technical
implications of that and it's use for "content push" and less about
integrating tools or building platforms.

PayPal seems to continue to be the example most people are familiar
with, however they (as well as I) complain about debugging since
PayPal doesn't document all possible events and payloads very well,
and doesn't have an easy test triggering mechanism like GitHub has.

I'm going to invite some of them to the conversation to follow up with
anything I left out.

-jeff

[Andy Kent (candyco)]

On 11 Nov 2008, at 01:18, Jeff Lindsay wrote:
> I gave my Web Hooks talk at the Hackers conference.

Great stuff, glad to hear you're still spreading the word Jeff.

> There was a lot of discussion about the core mechanic, technical
> implications of that and it's use for "content push" and less about
> integrating tools or building platforms.

Obviously there is a rather large difference between web hooks for
consumer use vs web hooks for developers.

It seems to me like the main barrier of entry for consumer web hooks
is the need to have a persistent endpoint to push content too. With
dynamic IP's, differences in content and most users only being online
for a fraction of the day it's impractical to push directly to users
without a reliable middle man to broker that information.

> PayPal seems to continue to be the example most people are familiar
> with, however they (as well as I) complain about debugging since
> PayPal doesn't document all possible events and payloads very well,
> and doesn't have an easy test triggering mechanism like GitHub has.

The PayPal documentation isn't great but to give them credit where
it's due they do have quite an extensive system for triggering test
IPN callbacks, but it is a bit hidden.

https://developer.paypal.com/cgi-bin/devscr?cmd=_ipn-link-session
PayPal developer sandbox login required.
This tool was a big help in working up the switchub/PayPal
integration.

The thing that makes paypal tricky I think is that they flatten all
data into http variables so you never know 100% what you will be
receiving. Sometimes you get price and other times you will get
price1, price2, price3 depending if there are multiple items in the
transaction. Most of the other web hooks choose to send this data as
more structured payloads in either xml or json. I like the fact that
the PayPal way is 100% HTTP but it can make things hard work to
develop with and I assume it makes it much harder for them to document
as well.

Keep up the good work Jeff,
Andy.