APIs are one of the key foundational technologies that makes digital business possible. APIs enable new ways of interacting with customers and expanding existing sales channels and partnerships for delivery of digital services and innovation. The rapid growth of embeddable developer services such as Google Maps, Twitter, Twillio, credit card processing, shipping calculators, and many many more open services would not be possible without APIs.
Over the past five years, REST APIs have emerged as the dominant form of API design. This didn’t happen by chance. REST APIs are popular because they provide a simple programming model, can provide a programmatic interface to just about anything, and scale very well for web and mobile applications. However, as the graphic below illustrates, the demands of digital business are driving the need for evolution of API design to support new application patterns and push the limits for what current API design approaches are capable of supporting.
REST APIs have historically been a great choice for enabling access to backend data and application logic, especially where there is a well defined set of data inputs and outputs that can be serviced through a simple Request/Reply message pattern. A REST API call always executes in the form of accepting a request and returning a response. Simple, but effective.
However, REST APIs are not well suited to the needs of the new class of emerging applications that monitor real-time data streams and use sophisticated analytics and machine learning algorithms to identify and act on business opportunities (exposed as events). An event is not an API call. It’s a notification that something has happened. Events don’t fit into the request/reply API pattern and need to be handled differently.
For example, events generated through streaming analytics are more dynamic and less predictable, typically have a limited window of opportunity to act on, and often act as a trigger to kick off more complex API flows that involve multiple downstream steps or actions.
Multi-step execution flows, mixed message exchange patterns, and the concept of event handling are not supported by the REST programming model. We need something different.
Developers who are out on the leading edge today working with some of these newer application patterns used in digital business recognize the inherent shortcomings of REST APIs in dealing with the realtime and dynamic nature of event-oriented application styles. They are actively experimenting with ways to handle more sophisticated messaging patterns and data flows that go hand-in-hand with evented APIs. In essence, they are trying to build smarter APIs.
REST APIs aren’t going away anytime soon. But for developers who are trying to build APIs that provide maximum flexibility and agility, evented APIs that go beyond REST and support mixed messaging patterns (like pub/sub and multicasting) are the way forward.
Here are some of the characteristics of evented APIs, along with some use case examples. Evented API can:
- Consume and generate events
- Support mixed message exchange patterns (request/reply, pub/sub, multicast, etc.)
- Interact with streaming analytics
- Leverage microservices architecture
- Provide much richer API functionality
TIBCO is investing in tooling and capabilities to help developers support evented API and have recently started an open source project on github, called Project Mashling. Project Mashing is a microgateway that allows developers to build composable event-driven microservices and APIs, based on the concept of flow based “recipes” using visual tooling. It’s extremely lightweight (<10MB) and can be embedded in edge devices or used for serverless applications. For more information, you can go to http://www.mashling.io
Join us on January 18 for a joint webinar with Gartner where we will be talking about evented microservices; why we need them, what they are, and challenges to consider in evented API design. You can register for this webinar by clicking on this link.
