Skip navigation

Category Archives: Perspective

I haven’t been posting here lately, but lots of amazing things have been happening in the world of webhooks. At SXSW I gave my latest version of a talk to explain webhooks, and I went on to describe the greater “evented web” that they unleash. It also explains some of the motivation I have behind all this.

Push/callbacks are better than polling.

This should be an easy argument. It’s not just more efficient, it’s more real-time. I once heard something like 40% of delicious.com requests returned 304 Not Modified. I imagine similar numbers for other popular sites. The more real-time you try to be with polling, the worse it gets. Don’t call us, we’ll call you. It’s more efficient.

RPC solutions provide more value than messaging solutions.

Although you can argue that RPC can be powered by messaging, and messaging can be used for RPC, the point is that they are different mindsets. RPC is about triggering code that does something. Messaging is about putting a piece of data in another bucket. When you try to call somebody, you usually don’t want to get their voicemail, right? This analogy goes even further in that, like voicemail, it must be checked on the other end. Messaging just pushes polling somewhere else.

More importantly, the focus on triggering code is central to this value proposition. Generative systems are more valuable than sterile systems. When did the web get interesting? When it became about more than just static content, and code was put in the loop to generate dynamic content. The point is that if you prioritize code to receive a message before humans, you open up many more possibilities.

RPC is about making things happen. Messaging stops short short of that by just moving data around.

HTTP is the defacto RPC protocol.

HTTP is everywhere. There are powerful free servers, clients in every major programming environment, and people know it well. It’s proven and it just works. HTTTP’s simple design also allows it to be extremely versatile. It’s basically the TCP of the application layer.

However, the best thing is that HTTP is RPC. This subtle fact has been true ever since CGI was introduced. We’ve gone through building RPC on top of it with XML-RPC and SOAP, but wisely settled on a form of RPC that’s just HTTP and is even aligned with HTTP semantics: REST.

If HTTP is RPC and HTTP is everywhere, it is our defacto RPC protocol. Especially for web applications that breath HTTP, it almost doesn’t make sense to think of any kind of inter-application communication that isn’t HTTP. Turtles all the way down!

HTTP RPC + Indirection = Webhooks

David Wheeler said, “All problems in computer science can be solved by another level of indirection.” Webhooks, and all callbacks, are about taking a procedure call and performing it on a variable function. This is indirection and this is very powerful. This is why Unix pipes work. STDIN and STDOUT are not hardcoded values, they’re variables that you can control.

Now imagine if all the web applications you used had extension points that you could effectively hook together with any other application. Well, that’s what webhooks are about.

Although it’s not the most compelling story, this blog post is a terribly effective analogy. So effective, non-techies can read it and “get webhooks” … in some cases leading them to rally for webhooks as much as I do! The analogy focuses on a non-computer, real-world analogy based on telephone calls. Then it follows up with a more concrete example that helps explain the possibilities:

A concrete example of a story made possible from webhooks that might be a useful scenario for many of you involves Twitter. Let’s say Twitter supported webhook callbacks for when somebody follows you. Right now you get an email, and from there you can decide what to do manually: follow them back, block them, or do nothing. I used to go out of my way to block users that I knew were spam bots, but now there’s so many it’s not worth the time. And of course I also generally follow back people that I actually know. If Twitter would simply call a script of mine whenever somebody followed me passing along the user ID, I could very easily run this logic in a PHP script or a simple App Engine app. Or perhaps I’d use Scriptlets (ahem, which was made exactly for these kinds of web scripts). It would work like this:

First, use the Twitter API to look up the user from the ID, and grab their name. Then use the Facebook API to check if that name shows up in my list of friends on Facebook. If so, use the Twitter API to follow them back. Otherwise, if they’re following over 1000 users and that number is more than twice the number that’s following them (which is roughly the heuristic I use manually), use the Twitter API to block them. All automatic.

Definitely worth the read, if I do say so myself. It’s also worth pointing people that want a quick understanding of webhooks. What kind of analogies have you come up with?

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.

Last month I talked about webhooks at Glue, a new conference on the “glue” of the web. One of the other speakers was Josh Elman of the Facebook Platform team. I ended up on the flight back with him, so we talked about webhooks. He seemed excited about them as a fan of the callback/hooking pattern in classical programming. In fact, he mentioned how they were experimenting with them already for notifications within the Facebook Platform, but he brought up the issue of batching. Something I hadn’t thought of before, but is important for large-scale implementations that are likely to be posting a lot of events to a target endpoint.

Later, when I read about Google Wave, and how they use webhooks in their API for creating bots, they mentioned that they may batch events. I’ve yet to crack open my Google Wave developer account and play with their implementation, but I’ve since realized a very simple convention for batching: JSON lists as the outer structure.

This works because an event object is ALWAYS going to be a key/pair object. So receiving code just has to check if the payload JSON is an array or an object. If it’s an array, handle each object inside as separate events. If it’s an object, handle as you would.

This doesn’t work for POST variables, since it’s very difficult to do arrays in general, but particularly as the outer data structure. It’s just not made to be able to do that. So this would require you to use at least JSON. It works in XML as well, but because there’s more variety in XML payloads, it’s probably harder to settle on such a simple convention as this.

Let me know what you think. Or if any of you already know how Google Wave batches events in their Robot API.

I forgot to mention it on here, but yesterday I gave a talk at Pivotal Labs. It’s a whole new talk that tries to get a little bit more into technical implementation details. The slides are also arguably more stylish. Pivotal recorded the talk, so video will be up soon, too. Until then, here are the slides.

And feel free to use these slides or bits from the deck for your own webhooks talk! You can download the original Keynote presentation here.

I have a quick story to share that shows how cool it is to have web hooks. I was writing another post and ended up going on a tangent with this, so I figured I’d give it its own post.

At the last SuperHappyDevHouse, I presented Get Achievements, an XBox Live-style achievement platform I built one night. The only thing was, it had no pretty aesthetic to it, so I rushed what you see there now during DevHouse so I could present it at our lightning talks. I was hacking with a designer friend up until somebody came upstairs to tell me I was up soon, but just then I was struck with a great idea: what if I could add achievements to the DevHouse wiki? Get Achievements requires you to make backend changes to your code, and PBwiki is a hosted service. However, PBwiki recently added web hooks, so theoretically I could use them to trigger the achievements. Could I rig it up in the time I had left?

What I needed to do was have an event in PBwiki POST to a URL on Get Achievements that unlocks an achievement. I needed something simple and quick, so I figured I’d make a login achievement. With this, if I login to the wiki, I’d be rewarded with fanfare and a box saying “Login Achievement Unlocked” as you can do with Get Achievements. But how can I make PBwiki POST to Get Achievements when you login? Well, I can’t, it’s a hosted service. But like I said, they had web hooks, and they included logging in as a hookable event.

At this point I was downstairs less than 10 minutes from my 5 minute lightning talk. I let some people go ahead as I rushed through this sitting on the floor with my laptop. I needed a place to write a hook script for PBwiki that would POST to Get Achievements. Very simple. AppJet was the first place that came to mind, and because I didn’t have to set up an application config file or upload anything with an SDK, I was able to add achievements to the SuperHappyDevHouse wiki in less than 10 minutes… thanks to hooks and AppJet.

I got up there and showed them how cool Get Achievements was, and then I dazzled them with a demo of the DevHouse wiki with a login achievement. Sure, it was more a demo of web hooks than Get Achievements at that point, and because not everybody knows what the hell I’m talking about most of the time, I didn’t get the standing ovation I was looking for, but it went well. I had to go around after, asking my friends if they really got how awesome what I just did was.

From idea to a (mostly) working demo for something that would normally involve making backend code changes, I did as a user, in a panic, terribly fast. Just an example of what’s possible in a world with web hooks…

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.

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!