Modern web and mobile applications often require real time information transfer from a server to a client. With a server able to push content to connected clients instantly, as it becomes available, the server does not have to wait for a client to request new data. This need may arise for multiple reasons, such as a developer wishing to use live chat on her website or notifying a user that a file has changed Dropbox. The solutions to these issues can be found within WebSockets and Webhooks.
Behind the Scenes
WebSockets are defined as an HTML5 specification, this specification defines an API that enables web pages, or other clients, to use the WebSockets protocol for a two-way, full-duplex communication channel operating through a single socket with a remote host. By not requiring clients to constantly open and close connections for data, WebSocket based applications place less burden on servers, allowing existing machines to support more concurrent connections.
The biggest advantage of using WebSockets, is that they detect the presence of a proxy server. This allows them to traverse firewalls and proxies, and automatically set up a tunnel using the HTTP CONNECT statement to pass through the proxy. This design allows a WebSocket to work well with existing Web infrastructure, however a switch from HTTP protocol to the WebSocket protocol is required, this is known as the WebSocket handshake. This always open communication channel is perfect for a live chat application. The architecture for this is depicted via the following figure.
In contrast to the WebSocket HTML5 specification with an always open communication channel, Webhooks are user-defined HTTP callbacks, where it is required that a socket stay open on the server and the socket is only opened on the client for the request. In short a Webhook is usually triggered by some event. When that event occurs the source site makes a simple HTTP request, akin to a standard REST request, to the URI configured for the Webhook. This architecture allows causal events on one site to invoke behavior on another, such as a file being changed on Dropbox alerting a disparate service that it has been changed.
The biggest barrier to using WebSockets is the overhead of spinning up a specialized server or paying for a service as well as implementing the API to integrate the system. Webhooks seem to bridge the gap between standard REST requests by making a single API endpoint that can be hit by an event and Websockets by leaving the server side socket open while only opening the client socket when a given event happens. The simplicity and power of Webhooks makes for an exciting future of communication not only within applications but between applications. The piggybacking of one Webhook calling another Webhook could maintain the fundamental decentralized nature of the web.
Microsoft ASP.NET WebHooks V1 RTM
Microsoft saw the prevalence of WebHooks being used in some of the most popular services and Web APIs, so they developed ASP.NET WebHooks V1 RTM to provide a common model for receiving and processing WebHooks from these services. It provides support for Dropbox, GitHub, Stripe and many more. In addition, it provides the tools for generating WebHooks for others to consume. With ASP.NET WebHooks the advantages of Webhooks can be seen in action, as Henrik F Nielsen says on his blog: "The purpose of Microsoft ASP.NET WebHooks is to make it both simpler and more consistent to wire up your API without spending a lot of time figuring out how to handle any WebHook variant."
Creating a custom WebHook with these new tools is painless, though this does require an Azure subscription. Just simply follow the instructions from Microsoft’s blog here