Les webhooks ont inversé l'API : au lieu de demander, les applications sont appelées quand quelque chose se produit

En 2007, les sites web disposaient d'API, mais l'intégration passait encore par l'interrogation répétée : une application frappait encore et encore à la porte d'une autre pour demander si quelque chose de nouveau s'était produit. L'article de blog de Jeff Lindsay, « Web hooks to revolutionize the web », plaidait pour appliquer au web l'idée des pipes Unix — de simples programmes chaînés les uns aux autres par leurs entrées et sorties — en permettant aux sites d'enregistrer des callbacks que d'autres sites appelleraient lorsqu'un événement se produirait.

Le design est radical par sa petitesse : un webhook est un callback HTTP défini par l'utilisateur. Vous donnez une URL à l'application émettrice ; lorsque l'événement se déclenche, elle vous envoie les données par POST. Pas de courtier de messages, pas de nouveau format de transmission, pas de nouveaux ports ni certificats — juste une requête sur le web que tout le monde fait déjà tourner. Chaque intégration est de pair à pair, si bien que le réseau se multiplie sans aucun coordinateur central.

Le modèle s'est répandu plateforme par plateforme. GitHub, Stripe, Shopify et Slack ont livré la prise en charge des webhooks, et dans les années 2010, une plateforme d'intégration comme Zapier pouvait le décrire comme la manière par défaut dont les applications « parlent » entre elles — le moment de l'e-mail push pour les applications, où le logiciel a cessé de vérifier pour commencer à recevoir.

Ne nous appelez pas — nous vous appellerons, en simple HTTP

Un webhook, c'est une URL, donc toute application peut en proposer un sans nouvelle infrastructure

Le push l'emporte sur l'interrogation répétée : aucune requête gaspillée et une livraison quasi en temps réel par défaut

Il repose sur du HTTP simple, donc les pare-feu, les proxys et TLS fonctionnent déjà

Les connexions de pair à pair se multiplient en réseau sans courtier central

La norme la moins coûteuse est celle qui ne nécessite aucune machinerie nouvelle. Si vous pouvez exprimer le nouveau modèle avec ce que tout le monde fait déjà tourner — une URL, un POST HTTP —, l'adoption se fait d'elle-même.

Les webhooks sont passés d'une idée d'outsider à un prérequis incontournable, et la simplicité a créé ses propres problèmes, autour desquels l'industrie s'est ensuite standardisée : les charges utiles sont désormais signées (Stripe a popularisé les signatures HMAC), les consommateurs ont besoin de nouvelles tentatives et de l'idempotence, et les récepteurs qui récupèrent des URL fournies par un attaquant sont devenus un vecteur classique de falsification de requête côté serveur que l'OWASP documente abondamment. Ce qui a commencé comme un article de blog est aujourd'hui la manière dont les paiements confirment, les déploiements de code s'exécutent et les applications de messagerie envoient des notifications.