Now that the publish and subscribe approach to doing APIs, formerly known as PubSubHubbub, has become a formal standard, which is now called WebSub, we wanted to take a moment and showcase what this architectural style brings to the table. Straight from the W3C page for the standard, “WebSub provides a common mechanism for communication between publishers of any kind of Web content and their subscribers, based on HTTP web hooks. Subscription requests are relayed through hubs, which validate and verify the request. Hubs then distribute new and updated content to subscribers when it becomes available.” Providing a slightly more sophisticated approach to delivering event-driven solutions using APIs, than just Webhooks alone can deliver.
WebSub represents the many ways we can orchestrate our API implementations using a variety of content types, push and pull mechanisms, all leveraging web as the transport. WebSub is an interesting approach because of its federated API approach, and the discovery that is built into the methodology by default. The remaining elements are pretty standard API stuff using GETs, POSTs, and content negotiation to get the job done. While not an approach that should be used by default, for specific use cases, delivering data and content to known consumers, Websub can be a useful tool in our event-driven toolboxes, and that WebSub has matured as a standard, and part of the wider W3C working group, it is an architectural pattern that is worthy of keeping a closer eye on, studying how providers are implementing, and thinking about how it fits into the bigger picture.
WebSub is made up of several key components, including a Publisher, which is an implementation that advertises a topic and hub URL, with a Subscriber that operates as an implementation to discover any hub and topic URL, subscribing to updates at the hub, and accepting content distribution requests from the designated hub. Additionally, a WebSub Hub is an implementation that handles subscription requests and distributes the content to subscribers when the corresponding topic URL has been updated. Each implementation operates independently, but are designed to be interoperable across implementations by using a shared standard. Providing a pretty compelling look at how we can deliver federated event-driven solutions, that are all working in concert to deliver meaningful content across a range of topics.
We are keeping a look out for interesting WebSub implementations in the wild, as we profile APIs as part of our Streamdata.io API Gallery. We consider WebSub as an important tool in our API toolbox, and an architectural pattern that is worth getting to know, and studying how API providers are putting to work. We’d like to better understand how WebSub channels might possibly be proxied using Streamdata.io, and turned into relevant topic-based streams. Adding to the possibilities for how event-driven architecture can be made more real-time, as well as more efficient using caching, and delivered using Server-Sent Events (SSE), and JSON Patch updates. Now that WebSub is a standard we expect to be seeing more implementations, and something that we’ll continue to showcase as part of the Streamdata.io API Gallery.