Skip navigation

Tag Archives: interviews

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.

Today I did a 7 question interview for Jason Salas on web hooks. Pretty standard stuff, but it allowed me to bring up some things I haven’t written about yet. His final question was about barriers going forward with the movement, which I also answered with a general “what’s coming” sort of response:

It seemed like the biggest hurdle originally was getting people to wrap their heads around this idea. I would always talk about it in the abstract and go on about all the implications of what was essentially one line of code. I think there are enough fairly well-known examples now that it’s easier for people to join the party. Even then, the general perception of what’s possible is going to be limited by the examples.

Like AJAX, you can’t just build a popular example of AJAX without it being a useful tool itself. I can build all the web hook prototypes I want, but it’s not until the Googles and Facebooks implement them in a useful way that people will really see the value. Until then, we get incremental boosts by the smaller companies like Gnip, GitHub, and others. I’ve started working or talking with these guys to get them involved in a collective conversation around web hooks, so we can work out issues standing in front of adoption.

The issues people come up with are usually security and scalability related. As it turns out, some of these issues have been solved by these guys already doing it. So I’m trying to get more of them to share best practices and publicize their use of web hooks. This way people can start seeing the different ways they can be used. For example, the Facebook Platform, although pretty complicated and full of their own technology, is still at the core based on web hooks. They call out to a user-defined external web application and integrate that with their application. That’s quite a radically different use of web hooks compared to the way people think of them in relation to XMPP.

Moving forward, I think we’re going to see more libraries and tools that have solutions to scalability and security built-in. I’ve started one project called Hookah that I’m hoping to get released soon. It provides basic callback request queuing and management of callback URLs so you really can implement web hooks with a single line of code for each event. We’re also starting to see similar helper libraries for frameworks like Django and Rails.

Eventually we’ll be seeing specs for doing specific things on top of web hooks. One of the first things on my list of standards to look into is the way in which you register and manage callbacks in a programmatic way. Many web hook providers use a web interface to manage your callback URLs. We’ll see some neat things happen when you can manage them via APIs so that tools can set callbacks with services on your behalf.

Anyway, one of the reasons I’m so attached to the idea of web hooks is that I see a lot of long-term potential. Especially when you integrate them into other visions of the future, like the Web of Things. When you combine the Programmable Web with the Web of Things, you get a world of Programmable Things.

That’s where I’d like to see this end up.