af83

À la découverte des webhooks

Logo des webhooks

Les webhooks sont un principe tout simple, mais qui offre de nombreuses possibilités pour étendre les fonctionnalités d'un site web. L'idée est vraiment simple : quand quelque chose de particulier se passe sur notre site, on envoie une requête HTTP avec le verbe POST vers une URL donnée. Les webhooks servent donc à notifier des scripts externes à une application web qu'un événement a eu lieu.

Hmmm, ça reste abstrait ? Prenons donc un exemple pour voir pourquoi et en quoi c'est très pratique. Github implémente des webhooks. Vous pouvez configurer pour un de vos dépôts git des URL de callbacks. A chaque fois qu'un commit aura lieu sur le dépôt en question, ces URL seront appelées avec les informations utiles (le nom du dépôt, la révision du commit, etc.). Cela offre de nombreuses possibilités : vous pouvez vous en servir pour déclencher un build sur votre service d'intégration continue (integrity par exemple), mettre à jour la documentation (rdoc.info offre ce service pour les projets ruby) ou encore analyser certaines métriques (Caliper).

Nous voyons que les webhooks peuvent donc servir à notifier très rapidement d'un événement. Mais ce hook peut également déclencher d'autres actions. Par exemple, le service d'intégration continue qui vient de recevoir un hook pourra lancer un build, puis poster le résultat sur un service de microblogging, et celui-ci pourrait alors lancer un autre webhook pour que les utilisateurs qui suivent ce compte soient notifiés, par exemple, en lançant qui script qui enverrait un message jabber, etc. Les webhooks sont cascadables à volonté.

Il existe une autre classe d'utilisation des webhooks : permettre à des script externes d'agir sur le site lui-même. Quand l'URL externe est appelée par un webhook, l'application peut lire le retour et agir en conséquence. Le cas le plus parlant est celui des robots sur Google Wave. Quand un utilisateur écrit dans une wave surveillée par un robot, celui-ci est prévenu par un webhook du contenu qui vient d'être écrit et il peut modifier la wave en réponse. Cela permet d'étendre le fonctionnement de Google wave via l'équivalent de ce que l'on pourrait appeler des plugins, mais avec la grosse différence que le code de ces plugins n'a pas besoin d'être sur le même serveur que la wave elle-même. On peut donc laisser la possibilité à des développeurs externes d'enrichir notre application de manière contrôlée.

Bref, les webhooks me semblent un élément de plus en plus important dans le web temps réel. L'alternative utilisée jusque là, le polling, devient de moins en moins adaptée à des contenus dont le rythme de mise à jour ne cesse d'accélérer. L'exemple de github est d'ailleurs assez symptomatique : il peut se passer plusieurs mois entre 2 commits, mais dès que j'ai commité, je souhaite que l'intégration continue se déclenche au plus vite afin d'être prévenu au plus tôt des regressions que j'aurais pu provoquer avec mon commit.

J'espère que cette introduction aux webhooks vous donnera envie d'appronfondir un peu le sujet, et surtout d'en mettre en place dans vos applications.

blog comments powered by Disqus