Continued from page 1.
It has many benefits for API consumers because it can support a granular, loosely coupled architecture where API consumers could create multiple microservices, each processing a different callback event from Stripe.
Like Stripe, GitHub, which is arguably the world's leading software-as-a-service (SaaS) code repository, provides Webhooks as a means of sending out-of-band events to API consumers. Examples of such events include:
- Branch or tag deletion
- A repository being forked
- Push and pull requests
GitHub allows developers to create Webhooks for an entire organization or for individual repositories, giving API consumers a reasonable amount of flexibility over how to configure their services. Again like Stripe, events can also be filtered at source, so API consumers tailor exactly which events should trigger notifications, with filters available to developers in their repository settings:
The GitHub example is also interesting because the events being pushed to the Webhook may not originate from activity on the GitHub API. Any organizational or repository activity can generate an event that can fire a callback to a registered Webhook, with the event being used to initiate activities such as code review or even triggering a message in a Slack channel. This shows how broad the application of Webhooks can be.
Twilio is a telecommunications API provider that delivers extensive capabilities via Webhooks for API consumers to receive events based on messaging and telephone call activity, categorized as "pre" and "post" events. The pre-event callback provides an API consumer the ability to apply rules that restrict certain events from taking place. For example, a developer can use a pre-event callback sent via a Webhook to prevent an SMS message from being sent or to halt a call taking place. Developers can use the Twilio Portal to configure both their Webhook URL and the type of events they wish to see:
Like the GitHub example, Twilio demonstrates the fact that Webhooks are not simply coupled to returning the results of long-running tasks that cannot be returned by a synchronous API call, they also allow developers to add interesting and useful functionality to their applications. Through these additions, developers can add value to the core features of the service they are consuming.
SlackTrack this API, the extremely popular team collaboration tool implements both incoming and outgoing Webhooks to allow users to integrate bots and services into their Slack channels in a very simple manner.
Incoming Webhooks in Slack's context are designed to make a developer's life easy by giving them an easy-to-use interface for posting unstructured data to Slack channels, which of course is how a bot initiates a conversation when prompted from an external stimulus; incoming Webhooks are, however, really a simple API call.
Slack's outgoing Webhooks are also extremely easy to configure and allow calls to be made to bots or external services to elicit a response in the channel. A developer is required to set a trigger word and URL and Slack will automatically POST an event to the URL; the developer's service needs only to respond with a simple JSON fragment with the property "text," the contents of which will be displayed in the channel.
Therefore, Slack outgoing Webhooks allow developers to make a conversational response very easily with minimal restrictions from Slack itself, enabling all manner of bot related integrations.
This is part one of our series on push technologies. In part two we will provide a primer on PubSubHubbub.