Web hooks
Update: Let’s get serious about this shall we? A wiki has been set up to support the growing community interested in web hooks.
A while ago I realized something about our ecosystem of web applications that sort of blew me away. Since then, I’ve been trying to run it by smart people whenever I get the chance. I keep reminding myself that I should blog about it, but I’m not a very well-disciplined blogger. Now, for some reason, I’m finally writing about it.
The idea is something I’m calling web hooks. They’re very simple server-side mechanisms for web applications that allow users to do what they want with their data. You just let them specify URL’s for various events that the application will use to pass data or notifications to in real-time.
I was called a communist for this idea, but whatever. I think they’ll take the web to a new level, similar to the way web API’s and RSS feeds did. The problem is, nobody is doing it, which is funny, because they’re easier to implement than REST.
API’s allow web services to talk to each other… as long as you wrote one of them, or the developer of one made the conscious decision to use the other. That, combined with RSS feeds, starts to imply the idea of the web as this platform of decentralized applications with inputs and outputs. Yeah, we talk about that, but that’s not exactly how it is.
You know what would be great is if two different web services could share data. The example I keep referring to is Basecamp and Harvest. We’d love to use Harvest at work for time tracking, but then we’d have to deal with maintaining two sets of overlapping data, in this case projects.
If Basecamp provided a web hook for project creation, meaning, they would pass project data to a URL we specify, we could write a script that would then post that data to Harvest using their API.
The idea isn’t about direct communication to other services, in fact, it doesn’t have to do have anything to do with making services share data. It’s just allowing the user to do what they want with it via HTTP. It’s really not that hard to learn how to use PHP and throw a script up somewhere. And if you don’t want to do it, with enough services using web hooks, it’s likely we’d see junction services that will adapt data from one service to another for you.
Web hooks don’t make sense for everything, but especially for applications that persist and manipulate user data, web hooks empower users by so much without much cost at all.
Now that I’ve introduced the idea, I’ll probably be talking about it more. As well as trying to convince people they should be implementing web hooks, I’m planning to use them myself. With DevjaVu, there’s a very obvious place for them exposing Subversion hooks, like post-commit and such.
Hopefully I can make an impact because a world with web hooks would be incredibly empowering.
November 27th, 2006 at 9:00 am
[…] In building the Transmutify prototype, and never having worked with receiving emails before, I realized it really sucks getting that to work. Which is unfortunate because it’s a great interface. Who doesn’t know how to send email? So Mailhook would be a place where you register a subdomain that would accept email and then make an HTTP post to a URL you specify (an example of a web hook) when it receives mail. This would make it as easy to accept emails as it is to accept HTML form submissions. […]
January 15th, 2007 at 6:15 am
[…] Pre-commit is used less often, but can be used to prevent commits when, for example, a log message isn’t provided. It could also be used to implement your own authorization scheme. Since we’re using HTTP for these hooks (hence they are web hooks), the way you tell us to prevent the commit with the pre-commit hook is to return 400 Bad Request, which we’re using here as a general error code to mimick the behavior of a shell script error code. Any output returned in the body will be displayed as the reason. […]
January 24th, 2007 at 8:37 pm
It’s a very good idea, from a SOA point of view; just getting the data out of the application without any predefined target makes it a lot more useful and open to end-user innovation. Thinking hard about what could be bad with it, I more or less come up blank. Using your web hook posting as a way of engineering an attack vector against other systems, with carefully wrought payloads? Certainly possible, but I can’t really see it would make much sense unless the intended effect was to taint your name. (It probably wouldn’t even work very well.)
I think the all-round best part of the idea is what lies behind it, in the one-up attitude of “it is your data; where do you want it served?”, rather than “it’s your data, we’re just holding it for you and letting you work with it”. That’s where you are really breaking new ground. But web hooks, for all lack of technical details above, might well be a large part of the way there.
March 26th, 2007 at 5:13 pm
Hi!
Could you explain web hooks more deeply? Does it mean that some application sends a message on an event to ALL who is catching this hook instead of manually downoading a feed? Or I’m misunderstanding something?
March 27th, 2007 at 4:54 am
An application would send a message on an event specific to a user to a URL specified by that user. Multiple if allowed by the application. The user could manually download a feed, but in order to achieve a real-time flow of information, you’re going to need to poll way often than you need to, so the application has to worry about caching, etc.
Feeds also aren’t made to support passing structured information. You could combine a feed with a REST API, but again, hooks would solve the problem with much less work.
March 29th, 2007 at 3:20 pm
You may want take a look at http://pingthesemanticweb.com/
“An application would send a message on an event specific to a user to a URL specified by that user. ”
But in this model user’s application must be always online, cos we don’t know when a message from a remote server.
March 30th, 2007 at 12:12 am
Pinging is a great example and maybe we’ll have hook relays like ping servers. However, it shouldn’t be necessary. The idea with the Internet is that it is always online. If you have a server, you want it to always been online. It’s not that hard to get cheap hosting to make your user script stay online %99.99 of the time as they say. In fact, you can get free hosting at places like Ning.
January 21st, 2008 at 9:47 pm
This sounds like Paypal’s instant payment notification: https://www.paypal.com/IntegrationCenter/ic_ipn.html
If you enable it, every time a payment comes in it posts back to the URL you specify with all the details of the payment. Your site can then insert a new order into its database, or correlate an existing order with the payment, or whatever. When I last worked with it (which I should add was long before REST was in vogue) I found it rather ingenious as being quite easy to work with.
January 21st, 2008 at 9:50 pm
Yes, payment gateways were the first to do anything like this when they would POST back to your site on payment success or failure. PayPal’s IPN is exactly a web hook.
February 1st, 2008 at 6:35 pm
I love this idea. Let the user decide how she wants to tie web apps/services together. The straight up simplicity of this idea is fantastic.
March 12th, 2008 at 10:08 am
Great idea. Simple but very powerful.
Now I’m thinking of how I can incorporate it into a few of my projects.