tl;dr

We should upgrade WebHooks so that they can be created by submitting a form/template of the callback request to be generated. This will allow users to connect APIs together arbitrarily without having to wait for providers to do the work to make it happen.

The long version..

In case you don’t know what “WebHooks” are, here’s a quote from the official wiki:

The concept of a WebHook is simple. A WebHook is an HTTP callback: an HTTP POST that occurs when something happens; a simple event-notification via HTTP POST.

A web application implementing WebHooks will POST a message to a URL when certain things happen.

WebHooks are great - they’re being used in a lot of places on the web, but they aren’t achieving their full potential. They haven’t had as big an impact on the web as they probably should.

One small improvement in how they are designed and implemented could lead to a huge gain in their usefulness. Before the solution, let’s look at the problem..

The Problem

Assume you are paying for two external services who both expose an API. One is a todo system, and the other is email delivery. Your todo service provide a WebHook that fires on completion of a task.

When you complete a task in your todo, you want it to make a WebHook request to the email service’s API and get it message you with an email saying “Tremendous. You finished #{the_task}”.

The problem is that the request emitted by your todo service is nothing like the request that your email service is expecting.

The Solution

If you were able to supply a template for the todo service’s WebHook, and not just a URL callback, then you could configure it to produce a request which would feed the email API and produce your desired outcome. So, the solution is to make WebHook’s more sophisticated and dynamic i.e. they are created by supplying a template of the request, rather than just a URL.

So you could configure your todo WebHook by submitting something like this:

https://gist.github.com/2024952

There are some other issues to address here such as auth (afaict, OAuth would work ok), but I think this presents a significant improvement in how users are able to compose together external services using WebHooks.

Any thoughts?

I believe the current proposal for offline web applications is too complicated, fiddly, and brittle. There is a cleaner and more efficient approach which makes better use of existing mechanisms of the web to negotiate and manage “offline assets”. Here’s a brief summary:

The essence of this proposal is that a proper solution to the offline web app problem should not require drawing a distinction between “offline” and “online” assets. There is no need for ‘cache manifests’, or to create a separate 'application cache’ from the standard browser cache.

This solution should leverage existing web caching infrastructure (i.e. HTTP headers such as Cache-Control, Etags, etc) to control how browsers store and negotiate the assets required to run the application offline.

Key to this solution would be browser cache compliance with the HTTP Cache-Control Extensions for Stale Content. In a nutshell, essential assets (html, javascript, css, etc) of the application required for offline usage would be served with a 'stale-if-error’ directive in the Cache-Control header. When the browser is taken offline and the origin server cannot be reached, all of these assets will be served out of the cache (due to the stale-if-error directive) and the application will continue to function.

That’s pretty much it.

There is one significant hurdle here, and that is the limited capacity and reliability of local browser caches. However, a relatively simple solution would be to create a new HTTP header with which a server can indicate the cache storage requirements of its application (by domain). Something like

> GET / HTTP/1.1
> Host: myapp.com
> ...

< 200 OK
< Cache-Storage: 160M
< ..... 

If this is the first time the browser has encountered this app then the user is prompted to grant access for the domain to reserve the disk space to 'install the offline app’. The user can then either accept, or reject (and optionally remember their choice).

Alternatively, the cache-storage value could be expressed as metadata in the <head> of the application’s main html document, however this would result in the pattern being unusable outside of html apps.

Either way, this would offer a familiar experience for users; where they are asked to 'install’ an offline web app in much the same way they would be by traditional desktop software.

When the reserved storage is full, any assets that were served with a stale-if-error directive must take priority in the reserved storage over those that weren’t.

Application developers can manage the way updates to individual assets are negotiated using HTTP’s standard caching mechanisms such as Cache-control max-age and ETag validations.

So that is the general gist of the proposal.. if anyone is interested let me know - perhaps we could try and flesh it out a bit more and push it forward. 

Cheers,
Mike
@mikekelly85