Skip navigation

I like to claim you can implement web hooks with one line of code. The reality is you need to do more than make inline HTTP requests. You need to manage user callback URLs, you need to make the requests asynchronous, you probably want a retry scheme, you might want authentication or verification, and in some cases a response handling mechanism. To do these things requires quite a bit more work, and those that have done it so far haven’t yet disclosed the details of how they’ve implemented this. I hope to change that, and to speed things up, I’ve started a simple community project I’m announcing today called Hookah.

The goal of Hookah is to take most of the work out of implementing web hooks. Ideally, Hookah will allow you to have all the features you need for successfully deploying web hooks and only need to add a few lines of code to your app. In fact, one line for each event! On top of that, the interface for Hookah is HTTP, so it’s not that different than directly invoking web hooks and works easily from any language.

The project is on GitHub and, as you can see, it’s very simple. Currently what we have in the master branch does asynchronous event dispatching with retries. This should be enough to get anybody started with web hooks. It’s written in Python for simplicity and readability, but Python is pretty ubiquitous and because it’s an HTTP server it doesn’t require you to know Python to use it. Again, it’s very simple and very early, but I hope it can be the start of a collective effort to make web hooks easier to implement.

For now we can bootstrap off the Web Hooks discussion group to talk about it, so if you have anything to say or ask, join up. There is a rough roadmap in the README and if you’re interested in contributing, let us know.

6 Comments

  1. Nice stuff. Seems like Hookah itself might callback to the calling application once it successfully does its work, for logging, etc. This might be a place to standardize a bit (and I’d suggest being RESTful and including the callback-callback url in a hypertext representation that you are posting to Hookah).

    • Peter, agreed! I was going to have it callback for outgoing callback responses (a nice way to handle asynchronous response handling), but having other hooks back to your application sounds like a Good Idea. As for standardization, we’re starting to talk about some of this on the GetPingd list at the moment. I’ll definitely want to integrate whatever we come up with where it makes sense in Hookah.

  2. I think the problem is that web hook code tends to be application, or especially language/framework specific. I’d totally share what I have, but it’s barely enough for a library. For example, a ruby port of Hookah would be easy to create… but I’d want to be able to configure to send JSON, or use a queue rather than a thread that gives up after 3 tries. Adding stuff like that could turn this tidy little lib into something more complex and less attractive to drop into your app. I definitely like the ideas around this though.

  3. Implementations might tend to be app/lang/framework specific, but I don’t think they need to be, right? That’s the point of this. Though it has to be written in a particular language, it is not a library, and so it doesn’t require your app to be Python to use it.

    Also, it will eventually be much more configurable and have optional features that people would like. Whether you have a JSON payload or not may or may not matter, and if you want a queue it should at least be easy to hack if not an explicit option. Anyway, that’s where I’d like it to go, which is not obvious in the code itself.

    So to re-iterate: it’s not a library. It’s a standalone daemon for use from any language. Obviously if you have something already, you don’t need this. However, I’d love it if you could share lessons learned from your implementation. :)

  4. Hey Jeff,

    The super light implementation is very interesting – when I was throwing together django-webhooks I was so focused on an implementation of generic listener / subscriber models that I didn’t really consider the performance of the hooks and decided I’d just run them from a DB queue with a cron job.

    I’ll be looking at plugging this into djhooks to make the requests real time.

    Thanks!

  5. John, cool. Nice work with django-webhooks btw.


2 Trackbacks/Pingbacks

  1. By Webhooks - Samples and Usage | Technology on 03 May 2009 at 10:59 pm

    […] As you can see from the image above and some of his posts, Jeff Lindsay likes to claim that all it takes is one line of code to enable these hooks but he admits that there is more to it than that, let me pull out a quote from one of his articles on this topic. I like to claim you can implement web hooks with one line of code. The reality is you need to do mor… […]

  2. […] for enabling and simplifying idempotent webhook processing. Jeff’s scriplets.org and Hookah are a great start. A worthwhile extension might be a webhook-based pubsub messaging cloud with […]

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: