One ringy-dingy, two ringy-dingy. The words surely call to mind – at least to those familiar with the 1960s/70s TV show Rowan and Martin’s Laugh-in – images of Lily Tomlin as telephone operator Ernestine. But the digital businesses of a very different era do not want to have to rely on manual machinations all too reminiscent of those that a switchboard operator of old would perform to bring parties together. No, to be a true digital business requires that connections be automated, not hardwired, says Dave Duggal, Founder and Managing Director, EnterpriseWeb LLC. Today, however, the world generally relies on manual integrations to make API-constructed composite applications and their interactions and transactions appear as if they are functioning in a seamlessly interoperable way, when in fact they are not. Dynamic APIs can change that.
EnterpriseWeb is promoting the idea of Dynamic APIs as a potential standard with bodies such as the Object Management Group (OMG) and the Industrial Internet Consortium (IIC). “You could never scale a global telecom network with switchboard operators,” Duggal says, and neither can the vision of a seamlessly connected world of digitized businesses be realized when the APIs that integrate services and systems are diverse to begin with, constantly changing, not normalized back to common sources and hard to manage. The result is that modifications to them often lead to breakdowns that arrive without notice, interrupting composite application processes and bursting the illusion of easy unity.
APIs can represent microprocesses and, in a world where everything is an endpoint, extract everything from databases, systems, machines, and devices for the Internet of Things. But how to efficiently and continuously coordinate that for applications built of these small units, each of which is a snowflake with a unique interface implementation: “If in my rich application, end-to-end we are connecting 30 things, every time one API changes, the whole app breaks,” he says.
“Model-driven API interoperability and evolution,” is how Duggal describes the Dynamic API concept that addresses the problem. “The idea is to move away from a discipline to a standard schema, a simple and lightweight way to communicate the model of the API.”
The approach avoids coding and endless integrations and re-integrations across endpoints. “Existing practices no longer support new demands. Manually coding and re-coding, and integrating and re-integrating simply doesn’t scale with Cloud and IoT,” he says.
The Dynamic API proposal promotes a Common Machine-Readable Pattern for describing heterogeneous endpoints as objects. The whole point of an object is to hide implementation details; but he says the trick is to not have statically defined objects (tightly coupled data and methods). “Our objects would be described as ‘deeply networked and highly-connected.’” They are, he says, graphs with conditional relationships – abstract data types, which mean that they must be interpreted for context. Specifically, the idea proposes normalizing all references to or having shared references to the API’s data model using links, policies, and human- and machine-readable Metadata. “Automate those, so Metadata is searchable, links are navigable and policies are executable,” he says. Accepting the fact of API change and agreeing on how to handle change in advance, instead of being tied to static schemas and implementations and tight coupling means that, at a minimum, when a publisher changes the interface to update, upgrade or replace a service, a consumer receives a realtime notification.
“If I have consistent semantics for making changes, I can anticipate change. So I can say when my app sees change, send out a message to the IT office or have systems negotiate the change on the fly,” he says.