vue d’ensemble des WebHooks ASP.NET

WebHooks est un modèle HTTP léger qui fournit un modèle pub/sub simple pour le câblage entre les API web et les services SaaS. Lorsqu’un événement se produit dans un service, une notification est envoyée sous la forme d’une requête HTTP POST aux abonnés inscrits. La requête POST contient des informations sur l’événement qui permet au récepteur d’agir en conséquence.

En raison de leur simplicité, les WebHooks sont déjà exposés par un grand nombre de services, notamment Dropbox, GitHub, Bitbucket, MailChimp, PayPal, Slack, Stripe, Trello et bien d’autres. Par exemple, un WebHook peut indiquer qu’un fichier a changé dans Dropbox, qu’une modification du code a été validée dans GitHub, qu’un paiement a été initié dans PayPal ou qu’un carte a été créé dans Trello. Les possibilités sont infinies!

Microsoft ASP.NET WebHooks facilite l’envoi et la réception de WebHooks dans le cadre de votre application ASP.NET :

• Du côté de la réception, il fournit un modèle commun pour la réception et le traitement des WebHooks à partir d’un certain nombre de fournisseurs WebHook. Il est prêt à l’emploi avec la prise en charge de Dropbox, GitHub, Bitbucket, MailChimp, PayPal, Pusher, Salesforce, Slack, Stripe, Trello, WordPress et Zendesk , mais il est facile d’ajouter une prise en charge pour plus d’autres.

• Du côté de l’envoi, il prend en charge la gestion et le stockage des abonnements, ainsi que l’envoi de notifications d’événements à l’ensemble d’abonnés approprié. Cela vous permet de définir votre propre ensemble d’événements auxquels les abonnés peuvent s’abonner et de les avertir en cas de problème.

Les deux parties peuvent être utilisées ensemble ou séparément selon votre scénario. Si vous n’avez besoin que de recevoir des WebHooks d’autres services, vous pouvez utiliser uniquement la partie récepteur ; si vous souhaitez uniquement exposer des WebHooks que d’autres utilisateurs peuvent consommer, vous pouvez le faire.

Le code cible API Web ASP.NET 2 et ASP.NET MVC 5 et est disponible en tant que système d’exploitation sur GitHub.

Vue d’ensemble des webHooks

WebHooks est un modèle qui signifie qu’il varie comment il est utilisé d’un service à l’autre, mais l’idée de base est la même. Vous pouvez considérer les WebHooks comme un simple modèle de pub/sub dans lequel un utilisateur peut s’abonner à des événements qui se produisent ailleurs. Les notifications d’événements sont propagées en tant que requêtes HTTP POST contenant des informations sur l’événement lui-même.

En règle générale, la requête HTTP POST contient un objet JSON ou des données de formulaire HTML déterminées par l’expéditeur webHook, y compris des informations sur l’événement à l’origine du déclenchement du webHook. Par exemple, un corps de requête POST WebHook à partir de GitHub ressemble à ceci en raison d’un nouveau problème ouvert dans un dépôt particulier :

{
  "action": "opened",
  "issue": {
      "url": "https://api.github.com/repos/octocat/Hello-World/issues/1347",
      "number": 1347,
      ...
  },
  "repository": {
      "id": 1296269,
      "full_name": "octocat/Hello-World",
      "owner": {
          "login": "octocat",
          "id": 1
          ...
      },
      ...
  },
  "sender": {
      "login": "octocat",
      "id": 1,
      ...
  }
}

Pour vous assurer que le WebHook provient bien de l’expéditeur prévu, la demande POST est sécurisée d’une manière ou d’une autre, puis vérifiée par le destinataire. Par exemple, GitHub WebHooks inclut un en-tête HTTP X-Hub-Signature avec un hachage du corps de la requête qui est vérifié par l’implémentation du récepteur afin que vous n’ayez pas à vous en soucier.

Le flux WebHook se présente généralement comme suit :

• L’expéditeur WebHook expose les événements auxquels un client peut s’abonner. Les événements décrivent les modifications observables apportées au système, par exemple qu’un nouvel élément de données a été inséré, qu’un processus a été terminé ou autre chose.

• Le récepteur WebHook s’abonne en inscrivant un WebHook composé de quatre éléments :

  1. URI pour l’endroit où la notification d’événement doit être publiée sous la forme d’une requête HTTP POST ;

  2. Ensemble de filtres décrivant les événements particuliers pour lesquels le WebHook doit être déclenché ;

  3. Clé secrète utilisée pour signer la requête HTTP POST ;

  4. Données supplémentaires à inclure dans la requête HTTP POST. Il peut s’agir, par exemple, de champs d’en-tête HTTP supplémentaires ou de propriétés inclus dans le corps de la requête HTTP POST.

• Une fois qu’un événement se produit, les inscriptions WebHook correspondantes sont trouvées et les requêtes HTTP POST sont envoyées. En règle générale, la génération des requêtes HTTP POST est retentée plusieurs fois si, pour une raison quelconque, le destinataire ne répond pas ou si la requête HTTP POST génère une réponse d’erreur.

Pipeline de traitement webHooks

Le pipeline de traitement Microsoft ASP.NET WebHooks pour les WebHooks entrants ressemble à ceci :

Les deux concepts clés ici sont récepteurs et gestionnaires :

• Les destinataires sont chargés de gérer la saveur particulière du WebHook à partir d’un expéditeur donné et d’appliquer des contrôles de sécurité pour s’assurer que la demande WebHook provient bien de l’expéditeur prévu.

• Les gestionnaires sont généralement l’endroit où le code utilisateur s’exécute en traitant le WebHook particulier.

Dans les nœuds suivants, ces concepts sont décrits plus en détail.