For close to twenty years, the “common standard” of APIs on the web has been summed up in one word: “RESTful.” Designers, developers, and software architects have promoted, debated, and derided the notion of RESTful APIs in successive waves over the years with all sorts of pundits declaring REST “dead” and offering some other current practice as “the new REST” or, even better, “the REST killer.” Probably my favorite rejoinder in this space is Matt McLarty’s “Overcoming RESTlessness.”
As the REST debate goes on, another important approach has continued to grow more common and, I think, more relevant for APIs today — that of event-based or as I like to call them, EVENTful API designs. In my visits with companies around the world, almost every one of them are working on adding EVENTful services to their API ecosystem. And there are quite a few variations on what EVENTful means. Martin Fowler’s 2017 article “What do you mean by Event-Driven?” is a solid introduction into the EVENTful space.
I see quite a few companies mixing both RESTful and EVENTful practices in their API designs. Many times a single service definition will contain both styles. The “Microservice Canvas” process documented by Matt McLarty and Irakli Nadareshvili even makes this mixing of RESTful and EVENTful clear and easy when creating services.
The stability of synchronous REST
The word “RESTful” covers a relatively wide range of design options. The most common is the CRUD (Create-Read-Update-Delete) pattern made popular in Leonard Richardson’s “RESTful Web Services” book. However, there are other versions of “RESTful” in common use. There’s the hypermedia REST of Amazon’s AppStream API and solutions like “long polling” (see BOSH) over HTTP. All of these approaches are synchronous — there is a fixed sequential order to the way data is sent and received.
One of the big advantages of Fielding’s REST style is that it focuses on creating a stable foundation in order to expose a wide-ranging set of capabilities. REST’s focus on using the HTTP protocol to publish resources using unique URLs is at the heart of why the web in general has been so successful in the last few decades.
Companies, large and small, have been copying the approach of Google, Yahoo, and others in building their own catalog of resources and URLs using definition languages like OpenAPI. This has resulted in a number of successful API-driven cloud-centric products and services like Salesforce, Twilio, Google Maps, and more.
However, while RESTful services work well for document-oriented and large-grained resources geared toward common web browsers, they have struggled to keep pace with not just the speed of change but also the demand for real-time interactive services brought about by cell phones and the exploding market of “smart” devices.
And this is where an EVENTful approach can be more effective.
The flexibility of asynchronous events
While RESTful systems focused on resources, EVENTful solutions focus on actions. And, more importantly, EVENTful solutions rely on asynchronous interactions. This opens up many more possibilities for building responsive, real-time solutions. That means an EVENTful design offers services the ability to request and respond in real time and to do it in a way that provides more flexibility in the way the data is shared, displayed, and mixed across devices and platforms.
There are lots of implementation patterns that fall under the EVENTful umbrella. The simplest is event notification — getting a “ping” when something happens (e.g. “a user updated their record”). A similar pattern is event-carried state or ECS. In this approach, the actual related data is “carried” along with the alert (e.g. “a user updated their record. here is the user object…”).
The pattern most people associated with EVENTful design today is commonly called event sourcing or ES. In the ES world, every event is expressed as a transaction that is shipped to anyone interested and is also recorded in a kind of “ledger” that holds all the event transactions. In the case of the user information we’ve been discussing, there would be a transaction that indicates the change of the data in each of the user record fields. This might actually be expressed as multiple transactions. One of the unique aspects of ES is that most all transactions that change state can be “reversed” with another transaction. This is often equated with basic accounting ledgers where debits can cancel out credits in the ledger.
There are other EVENTful approaches like web hooks, publish-subscribe, and command-query responsibility separation (CQRS). The most common element in all these patterns is the reliance on asynchronous interactions — the decoupling of the requests and responses — that leads to another common expression: Eventual consistency.
The propagation of these transaction messages may take time and various “ledgers” may not be exact copies of each other at different points in time. However, eventually these multiple storage centers will be consistent with each other. Eventual consistency is a feature of asynchronous systems that helps them scale better as your system and volume grows.
Summary
As the number of microservices in an organization grows there’s a likelihood that the number of EVENTful interactions will increase, too. Microservices are often better at scaling and recovery when asynchronous interactions are involved. They’re not easier to design and manage, though. And that’s an important realization. If your organization is looking to add more real-time events, you’ll need to learn how to design, build, and manage asynchronous services and APIs.
Of course, this rise in EVENTful patterns does not mean you need to dial back on your RESTful work. By all indications, companies are adding EVENTful solutions even while they continue to bolster their investment in RESTful, synchronous interactions. In fact, a popular approach is to provide both RESTful and EVENTful at different endpoints within the same service. For example, APIs might support HTTP POST to create new records and also support a “RecordCreated” event that fires off once the POST action has completed.
Think of EVENTful patterns as more tools in your kit as you work to design and build great APIs for your customers.
To see how MuleSoft supports event-driven patterns using a reactive engine, check out our Mule runtime engine.
