Image de couverture de l'article PHP Tour : retour de conférence sur les webhooks !
Retour aux articles

L'agence

WanadevStudio

PHP Tour : retour de conférence sur les webhooks !

Wanadev s'est rendue au PHP Tour de Clermont-Ferrand les 23 et 24 mai 2016. En bons passionnés, nous avons décidé de faire quelques compte-rendus de ce que nous avons vu. Et nous avons vu des Webhook !

Pour ce retour, j'ai décidé de vous transcrire une synthèse de la présentation de Guillaume Potier qui était venu pour représenter son entreprise Wisembly et nous parler de WebHook.

Qu'est-ce qu'un webhook ?

Un webhook est un callback que l'on déclare sur une plateforme et qui appelle un server endpoint (comprenez une URL) lorsqu'un événement est déclenché.

Où trouve-t-on des webhooks ?

Les webhooks sont présents à peu près partout. Guillaume a souvent pris l'exemple de GitHub et de Google qui en utilisent beaucoup. Pour le premier, cela permet par exemple de communiquer avec des services comme Travis et Circle CI.

Un exemple d'utilisation ?

Vous déclarez un webhook chez GitHub via l'interface qu'ils ont mis à disposition. Vous indiquez que vous souhaitez être informé lorsqu'une Pull Request est envoyée, et que l'URL http://www.afup.org soit appelée. Et c'est à peu près tout ce qu'il faut savoir !

Mais comment je m'en sers de ce webhook ?

Quand les webhooks sont exécutés, ils appellent le server endpoint avec une méthode de type POST (dans la majorité des cas). À ce moment, le contexte est envoyé. Par exemple, dans le cas de GitHub, quand une Pull Request est envoyée, le contexte injecté en POST reprendra le nom du repository, son owner, le numéro de la PR, son URL et d'autres informations permettant de donner le contexte.

Voici la documentation du fonctionnement d'un Webhook à la sauce GitHub.

Ces informations doivent vous permettre de traiter l'événement selon vos cas d'utilisation.

Quel intérêt d'utiliser un webhook plutôt qu'un CRON associé à une requête sur une API ?

Les webhooks sont à privilégier lorsqu'on souhaite être informé du changement d'un état. L'avantage est que c'est le service tiers qui fait l'effort de vous prévenir.

Dans le cas d'un script contenant un appel à une API tierce (où on retrouverait les mêmes informations), c'est que notre script va être appelé régulièrement alors que ce n'est pas toujours nécessaire. Cela va entraîner un stress permanent de la machine distante (Flood).

Comment implémenter un service de webhook sur sa plateforme ?

On a tout simplement besoin de pouvoir définir des règles dans lesquelles on va donner une payload URL qui n'est autre que notre server endpoint, une liste d'événements qui vont entraîner l'exécution de notre webhook et éventuellement une secret key pour signer le contenu envoyé et attester que le service à l'origine de l'appel est bien celui attendu.

Au niveau du code métier, Wisembly prône l'utilisation d'un event dispatcher pour facilement lever des événements dans le code lorsque les webhooks doivent être exécutés.

L'event dispatcher envoie alors un message broker de type RabbitMQ. Un « consummer » écoute le RabbitMQ de manière asynchrone et réalise les appels vers les endpoints enregistrés pour l'événement levé.

Comment gérer ses webhooks ?

Guillaume a également abordé la question « Comment gérer ses webhooks ? ». Sa réponse a été simplement de miser sur une documentation complète, détaillée et à jour. What else ?

Retrouvez directement le support de présentation de Guillaume ici :

Commentaires

Il n'y a actuellement aucun commentaire. Soyez le premier !