API usage has absolutely transformed IT in the sixteen years since inventor Roy Fielding originally outlined the concept. At this very moment, millions of APIs are at work, opening up access to useful resources and data belonging to the businesses providing them while allowing other developers to apply their creativity in coming up with new methods and solutions. Developers create new services, new bridges of communication between businesses, and new efficiency and automation of business functionalities, all based upon the utility that APIs make available. The sets of tools that APIs conveniently enable developers to tinker with have led to countless innovations, including so many technologies we all rely upon today.
The practice of using APIs certainly has plenty of room to improve, and forward-looking developers will recognize that we’re only at a middle stage in the evolving ease with which communication between different pieces of software could potentially be achieved. A fundamental challenge in working with APIs is that developers must grapple with creating duplicate hard code for each language in which they make an API available. These multilingual versions of the same code all serve the exact same function, but a business with clients that require these copies must go to the trouble of maintaining this duplicate work.
At the same time, APIs face a substantial technical hurdle because different APIs work at different speeds. A developer needing to coordinate multiple APIs—say, one API able to handle 60 requests per second and another built to withstand a load of 40—has to produce “buffers” alongside the hard-coded logical binding she must implement to force those APIs to synchronize. In this way, argumentative APIs require developers to act like therapists, investing time and patience to get service components to communicate without discord when they aren’t naturally inclined to play nice.
A better way forward would be a solution that stands independent of individual programming languages, and which is much more simple than an API to scale, copy, and change. A powerful way to achieve this is to make the transition from APIs to ready-to-go, API-based processes. This is easy to envision if you think of APIs as the means of creating a product and processes as those end products. An API is a grocery bag full of useful ingredients. A process is a fully-cooked meal. Imagine a future where we no longer distribute APIs (and the painstaking hardcoding efforts included as a requirement of making them useful). Instead, we distribute processes designed to integrate with plug-and-play simplicity into any business’s systems.
Gartner analysts have investigated this scenario as well, foreseeing an “algorithm economy” in which these specific processes are sold as piecemeal tools and plugged into a business’ core systems to bolt on certain desired capabilities. This means that any developer at a company lacking a needed functionality—or suffering from any precise technology need that a tool exists for—can instead buy a working solution and put it to a job without facing the time, effort, and challenges of developing an equivalent solution internally.
Currently, so many businesses that are not natural IT companies must masquerade as such in order to function, enlisting too much developer time (time better spent elsewhere) to solve the same issues and provide the same solutions as at the next competitor over. Of course, these efforts are redundant and not the best focus or use of resources for companies outside the technology field, which might do better to compete on what they do best and not on their performance as a technology developer, if only an alternative was available. The introduction of process solutions that businesses can simply buy on the market and depend upon will amount to yet another transformation of IT landscape, as major a shift and an accelerator of innovation as the API revolution that preceded it.
By Alexander Vityaz, CEO, Corezoid