Dela via


översikt över ASP.NET WebHooks

Varning

ASP.NET WebHooks är inaktuell och får inte längre uppdateringar eller säkerhetskorrigeringar.

WebHooks är ett enkelt HTTP-mönster som tillhandahåller en enkel pub/undermodell för att koppla samman webb-API:er och SaaS-tjänster. När en händelse inträffar i en tjänst skickas ett meddelande i form av en HTTP POST-begäran till registrerade prenumeranter. POST-begäran innehåller information om händelsen som gör det möjligt för mottagaren att agera därefter.

På grund av sin enkelhet exponeras WebHooks redan av ett stort antal tjänster, inklusive Dropbox, GitHub, Bitbucket, MailChimp, PayPal, Slack, Stripe, Trello och många fler. En WebHook kan till exempel indikera att en fil har ändrats i Dropbox, eller så har en kodändring gjorts i GitHub, eller så har en betalning initierats i PayPal, eller så har ett kort skapats i Trello. Möjligheterna är oändliga!

Microsoft ASP.NET WebHooks gör det enklare att både skicka och ta emot WebHooks som en del av ditt ASP.NET program:

  • På mottagarsidan finns en gemensam modell för att ta emot och bearbeta WebHooks från valfritt antal WebHook-leverantörer. Den levereras direkt med stöd för Dropbox, GitHub, Bitbucket, MailChimp, PayPal, Pusher, Salesforce, Slack, Stripe, Trello,WordPress och Zendesk men det är lätt att lägga till stöd för mer.

  • På sändningssidan finns stöd för hantering och lagring av prenumerationer samt för att skicka händelsemeddelanden till rätt uppsättning prenumeranter. På så sätt kan du definiera din egen uppsättning händelser som prenumeranter kan prenumerera på och meddela dem när saker händer.

De två delarna kan användas tillsammans eller isär beroende på ditt scenario. Om du bara behöver ta emot WebHooks från andra tjänster kan du bara använda mottagardelen. Om du bara vill exponera WebHooks för andra att använda kan du göra just det.

Koden riktar sig ASP.NET Web API 2 och ASP.NET MVC 5 och är tillgänglig som OSS på GitHub.

Översikt över WebHooks

WebHooks är ett mönster som innebär att det varierar hur det används från tjänst till tjänst, men den grundläggande idén är densamma. Du kan se WebHooks som en enkel pub/undermodell där en användare kan prenumerera på händelser som inträffar någon annanstans. Händelsemeddelandena sprids som HTTP POST-begäranden som innehåller information om själva händelsen.

Vanligtvis innehåller HTTP POST-begäran ett JSON-objekt eller HTML-formulärdata som bestäms av WebHook-avsändaren, inklusive information om händelsen som orsakar att WebHook utlöses. Till exempel ser en WebHook POST-begärandetext från GitHub ut så här som ett resultat av ett nytt problem som öppnas på en viss lagringsplats:

{
  "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,
      ...
  }
}

För att säkerställa att WebHook verkligen kommer från den avsedda avsändaren skyddas POST-begäran på något sätt och verifieras sedan av mottagaren. Till exempel innehåller GitHub WebHooks en X-Hub-Signature HTTP-huvud med en hash av begärandetexten som kontrolleras av mottagarimplementeringen så att du inte behöver bekymra dig om det.

WebHook-flödet går vanligtvis ungefär så här:

  • WebHook-avsändaren exponerar händelser som en klient kan prenumerera på. Händelserna beskriver observerbara ändringar i systemet, till exempel att ett nytt dataobjekt har infogats, att en process har slutförts eller något annat.

  • WebHook-mottagaren prenumererar genom att registrera en WebHook som består av fyra saker:

    1. En URI för var händelsemeddelandet ska publiceras i form av en HTTP POST-begäran.

    2. En uppsättning filter som beskriver de specifika händelser som WebHook ska utlösas för.

    3. En hemlig nyckel som används för att signera HTTP POST-begäran.

    4. Ytterligare data som ska ingå i HTTP POST-begäran. Detta kan till exempel vara ytterligare HTTP-rubrikfält eller egenskaper som ingår i HTTP POST-begärandetexten.

  • När en händelse inträffar hittas matchande WebHook-registreringar och HTTP POST-begäranden skickas. Vanligtvis görs ett nytt försök med genereringen av HTTP POST-begäranden flera gånger om mottagaren av någon anledning inte svarar eller om HTTP POST-begäran resulterar i ett felsvar.

WebHooks-bearbetningspipeline

Microsoft ASP.NET WebHooks-bearbetningspipelinen för inkommande WebHooks ser ut så här:

ASP.NET WebHooks Processing Pipeline

De två huvudbegreppen här är Mottagare och hanterare:

  • Mottagarna ansvarar för att hantera den specifika smaken av WebHook från en viss avsändare och för att framtvinga säkerhetskontroller för att säkerställa att WebHook-begäran verkligen kommer från den avsedda avsändaren.

  • Hanterare är vanligtvis där användarkoden körs för att bearbeta de specifika WebHooks.

I följande noder beskrivs dessa begrepp i mer information.