Skip navigation

Category Archives: People

A while back I was interviewed on the Nearsoft blog about webhooks. It goes into more details on the whole push, pipes and plugin use cases. Real-time web is a hot topic these days, so I had to mention how the webhooks movement relates to that trend. Here’s an excerpt about using webhooks for real-time notifications:

Notifications seem to be [a big draw for webhooks] … as in, tell me when something new has been posted, or when something has changed. But with your code on the receiving end of the notification, you can decide exactly how you get notified. For example, tell me about changes over Twitter, not email. In fact, no, use this other hook script that uses cloud telephony to call my cell phone and use text-to-speech to tell me.

Real-time notifications, exactly how you want them.

The webhooks ecosystem is growing pretty fast and it’s really hard to keep up! There’s also a growing number of webhooks evangelists giving talks and writing blog posts about webhooks. It would be great if we could work together to help push this movement even further.

I really would like this blog (and eventually website) to be a place to learn about how to implement webhooks, best practices, and standards, as well as a place to see the movement grow. This means seeing services adopt webhooks, how they’re using them, how their users are using them … new services that provide infrastructure in this kind of event-driven programmable world… and software projects that help. Not just my projects like Hookah and Protocol Droid (yet to be announced), but all the plugins people are writing for various frameworks and open source projects.

So we need more writers on this blog. A lot of people send me links to services that adopted webhooks and I wish I could write about them all. I usually mention them on my Twitter, but that’s not enough to really say everything worth saying about some of them.

If you’d like to join us and write on this blog about webhooks, recurring or as a one-off piece, about anything from how you implemented webhooks, to how you did something clever with them, or why people should adopt them … get in touch with me. :)

A few days ago at BarCamp Miami, software architect Ryan Teixeira gave a talk about web hooks loosely based on my Programmable World of Tomorrow talk. It would have been nice to see, but I guess the next best thing is to see the slides on SlideShare. Take a look:

 

 

Nice job, Ryan!

Timothy Fitz recently wrote on What webhooks are and why you should care. It’s a very clear and straightforward description of just that. It helps to have people other than me talking about web hooks. Granted, Timothy is a good friend of mine, but it did spark a good discussion in his comments and on reddit.

webhooks08_udell135Also, Jon Udell brought up web hooks in a recent post regarding Assembla’s usage of the model. It shouldn’t be a surprise that he considers the adoption of web hooks a game changer. I still quote him in my presentations for envisioning in 1997 “a new programming paradigm that takes the whole Internet as its platform.” It’s an idea I’m quite fond of that I believe requires more than web APIs.

While I’m at it, Joe Gregoria posted his initial reaction of web hooks last week. His major critique was the lack of rigorous text around the model. Certainly I write a decent amount about them, but I avoid specifics. My focus right now is sharing the big picture, getting people to implement them on their own, and documenting the different discoveries along the way. I personally don’t feel a need to try and standardize very much yet, but perhaps better specifics on “how to provide web hooks” would be a good thing to get documented.

I’m glad a wider discussion is starting to emerge. I’ve stumbled across several other blog posts on web hooks recently. Some of the issues people bring up are authentication, scalability, and reliability. I plan to cover these issues in upcoming posts since they’re pretty straightforward, but you’re all welcome to participate in this discussion. Feel free to join our discussion list, write a blog post, leave a comment, tell your friends, or best of all: try implementing the model yourselves.

Speaking of the discussion recently, it was pointed out that Uche Ogbuji started publicly thinking about this about the same time I did in 2006. He called them web triggers as inspired from the database world. I chose web hooks coming from the programming world. There are a lot of words that describe different aspects of the same pattern: events, signals, callbacks, hooks, triggers, handlers, listeners… I stuck with hooks not just to keep the name simple to pronounce and differentiable from common code-level event terminology, but I also liked the idea of “programmability” it implies.

Blaine Cook

It’s been a busy week for web hooks, eh? Well, I figured I might as well share a quick note I received while writing the Amazon post. Blaine Cook, former architect of Twitter, sent me a message after finding a post in which I said he was the one preventing Twitter from providing web hooks. You see, I gave my first public talk on web hooks at an event called SuperHappyDevHouse in 2007. Afterward, Alex Payne came up to me and said, “This is great, I’d love to put this in Twitter.” But it never happened, and I was under the impression Blaine was the one that shot the idea down.

Anyway, he sent me a message saying that although he thinks it’s unfeasible for Twitter to provide web hooks at their scale, he’s all for them in principle. In fact, he says his next project will have web hooks from the start, which is exciting to hear.

But I’m still not convinced Twitter is completely unable to provide web hooks. The fact they let you get all notifications via SMS means they’re either making a web request or at the very least, sending an email. Why can’t they asynchronously queue up the outgoing HTTP requests for users that want web hooks?

Anyway, the Twitter argument is for another time. I look forward to seeing what Blaine is up to and how he’s using web hooks.