I’ve been loosely following the webhooks idea for awhile and I quite like it. I’m hoping to see more sites and services add support for web hooks, allowing my own services to consume data and events more or less as they happen.
Late last night while trying to get Michael to go to sleep I started thinking about the different ways we provide data to users. Feeds (RSS & Atom) have become really popular and are fine for what they do. Then my thoughts turned to email. I still get quite a bit of information via email. In thinking about feeds versus email, feeds are still mostly about polling for updates (or pings or pubsubhubbub). Email is potentially event driven, but in many cases you still have to poll for new emails.
That’s when in hit me. What I really want is web hooks for my Gmail account! I could filter in Gmail for certain email patterns and have those emails skip the inbox, go directly into my archive and have a copy of the email passed off to a URL of my choosing for further processing. All without having to poll for new emails, they would be pushed out to the URL automatically.
Now to be fair you could get something close to this already. If you have an email server you could have Gmail forward a copy of the email to your email server which could then pass it off to a script instead of delivering it to an inbox (did this with email aliases and procmail for years). But in my case I’m using Gmail in part because I got tired of running my own email server, I wanted to spend that time doing other things.
By why limit this to just Gmail? Why not have web hooks available for Google Reader or Google Calendar? A hook could get called anytime a change is made to my calendar, or a new item shows up from a blog with a specific tag. Then there’s Google Docs, hooks that would get called when ever someone besides me edits a document. There are any number of possibilities.
Now for the icing on the cake. Combined the power of web hooks with solid APIs for the services that call these hooks (Gmail, Google Calendar/Reader/Docs, etc.) and then you have something almost magical. The URL end points that process the hook data can turn around and update that data again, at the source. In the Google Calendar case a web hook that was called for invites, the hook could turn around and accept or decline that invite. This allows me to come up with my own means of processing, interacting with and responding to events.
Google has already started down this road with support for post commit web hooks on Google Code. Hopefully that is just the beginning.