This project provides a set of .NET tools for the management of subscriptions to events, basic transformations and notifications of such event occurrences (webhooks): in a global design scope, this model enables event-driven architectures, triggering system processes upon the occurrence of expected occurrences from other systems.
Although this integration model is widely adopted by major service providers (like SendGrid, Twilio, GitHub, Slack, etc.), there is no formal protocol or authority that would enforce a compliance (like for other cases, such as OpenID, OpenAPI, etc.).
Anyway, a typical implementation consists of the following elements:
- Webhooks are transported through HTTP POST callbacks
- The webhook payload is represented as a JSON object (or alternatively as XML or Form)
- The webhook payload includes properties that describe the type of event and the time-stamp of the occurrence
- An optional signature in the header of the request or a query-string parameter ensures the authenticity of the caller
I tried to express the concepts in more details in this page within this repository (without any ambition to be pedagogic).
While working on a .NET Core 3.1/.NET 5 *aaS (as-a-Service) project that functionally required the capability of users of the service being able to create system-to-system subscriptions and notifications of events through HTTP channel (that is typically named webhooks, or HTTP callbacks), I started my design with the ambition to use existing solutions, to avoid the bad practice of reinventing the wheel, but I ended up frustrated in such ambition:
- Microsoft's ASP.NET Webhooks project was archived and moved back to the Microsoft ASP Labs (that has no visibility on its release), aiming one day to provide compatibility with .NET Core (which eventually evolved, becoming LTS)
- Both Microsoft's projects (the legacy and the experimental ones) are not compatible with the latest .NET stacks (.NET 5 / .NET 6)
- Microsoft's experimental projects never implemented any capability of handling subscriptions, and eventually removing also the sender capability, focusing exclusively on receivers
- Alternative implementations providing similar capabilities are embedded and organic part of larger frameworks (like ASP.NET Boilerplate), that would have forced me to adopt the the entirety of such frameworks, beyond my design intentions
We would like to help you getting started with this framework and to eventually extend it: please refer to the Documentation section that we have produced for you.
Contributions to open-source projects, like Deveel Webhooks, is generally driven by interest in using the product and services, if they would respect some of the expectations we have to its functions.
The best ways to contribute and improve the quality of this project is by trying it, filing issues, joining in design conversations, and make pull-requests.
Please refer to the Contributing Guidelines to receive more details on how you can contribute to this project.
We aim to address most of the questions you might have by providing documentations, answering frequently asked questions and following up on issues like bug reports and feature requests.
This project is released under the Apache 2 Open-Source Licensing agreement.