Skip navigation

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 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.


  1. HTTP isn’t RPC it’s a state transfer protocol – there is value in drawing that distinction, it’s in the dissertation.

    I like web hooks, and it’s possible to explain them by means of state transfer, rather than remote procedure calls.

    I think a good way to look at webhooks is through the layered constraint of REST – or simply as a way of moving HTTP towards a p2p model by bending the client in the client/server constraint to include servers themselves. Roy actually mentioned this briefly during a talk in 2007.

    • I think your point is theory vs practice. I argue HTTP is RPC because of CGI, which is not part of HTTP as a protocol.

      I would rather explain webhooks as RPC just because it’s easier and probably just as effective. Like REST, I think proper semantics will come back in once it’s more widespread.

      Anyway, I’m open to learning more about how we can do that. I just don’t have the time. I’m all for ideal theories, but they have to be iterated towards over time to be aligned with practicality. So I imagine over time, I’ll find time to think about this more.

  2. I was ‘push’ing HTTP at a presentation last weekend to various SAP hackers at a great SAP tech unconference – SAP Inside Track, Bonn ( Open standards and protocols are still relatively new to the techies in the SAP world, but I’m happy that everyone grokked it.

    Funnily enough, one of my (rather terse) slides reflected something you said above: “HTTP is everywhere”.

    Kind regards

  3. I’ve gone through this entire blog and did not find one lien of code or one example.

    No, I didn’t watch your video or viewing your slides. I’m very busy and don’t want to sit here and watch something over a long period of time.

    If you can’t be bothered to even to attempt to explain what the heck this stuff is about in a short and concise manner, then how do you ever expect people to get it?

    Show me the code. One example would probably be enough. Just one.

    • I have been explaining it. Quite concisely in some cases. Apparently it’s “so simple it’s stupid.” You might just be missing something. I don’t think an actual code example helps… a toy code example sort of works. Try this: … Skip to slide 15 and click through.

      Seriously, I’ve been trying to simplify this for 4 years. Sometimes it’s hard when you’re that entrenched. But apparently it works well enough. Google, WordPress, GitHub, Pivotal, and many many others (see slide 42 for a sampling) have figured it out from my poor attempts at explaining.

      • Which doesn’t tell me one darned thing about implementation.

        I’m a programmer. I need to see example code. Without example code, I have no idea what you’re talking about.

        Basically, you’re talking about doing HTTP POSTS on events. Great, but that’s not revolutionary enough of an idea to have a name like “webhooks”, IMO. Where’s the protocol? Where’s the implementation? Where’s the spec?

        In short, where’s the meat in this sandwich?


    • There is no spec. Some specs have come out of it like PubSubHubbub. There are common patterns and tools. Obviously I disagree that it doesn’t deserve a name. It *is* as simple as you think. If you don’t think that’s a big deal… ignore what’s going on here. Obviously I do. Go through my talks to find out why … or not. Whatever.

  4. Hi, this is Jesus.

    Shut up Otto.

    Peace a love

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: