Throughout history, it has not been just once, twice, or three times that the machinery of technological marketing, in the absence of innovation, has had to invent concepts with little technical basis or argument, give content to not very solid concepts, or simply reinvent the wheel with new terms that keep a market fresh. This market, aside from its evident and accelerated exponential growth, does not always do so with the same intensity or speed in all its areas.
I believe this applies to the concept of API virtualization, where, in the absence of a real resource to virtualize an API, the marketing market has been limited to baptizing and dressing up with virtualization attributes an operation of very dubious credit. This basically boils down to cloning a productive instance in pre-production, staging, or test environments. From my humble opinion, this is far from what we might imagine as API virtualization, and without that adjective, what is now said to be done has already been happening for many years.
So, what should the concept of API virtualization really offer?
There is a term we coined some time ago at 101OBEX and have been working with for years, referring to dynamic APIs, to refer to an API that, even when part of an API Product within a certain API Catalog, can be loaded or unloaded from a project. That is, its existence as an element within an API catalog is not always certain and depends on whether it is activated or not. Therefore, its endpoint is also dynamic.
The concept of dynamic APIs has been very valuable mainly when applied to the development of private APIs within a public API Catalog and the distribution of these APIs to all or part of the developer teams in the same or another project.
As part of good governance and administration of APIs within an API Catalog, it is very useful to work with concepts of static and dynamic APIs, which allow us to differentiate public from private APIs and manage their availability based on project requirements. This offers an improvement in resource management and helps programmers get more out of their work, being exploited when necessary by other programmers in the same project or others.
Moreover, if we understand that in the API world, the sale of apified products goes through the direct sale of pre-parametrizable API Products, the creation of dynamic APIs within these projects becomes even more important.
API virtualization should be an evolution of dynamic APIs or a complementary element to dynamic APIs, allowing programmers to work with APIs that really do not exist, or better said, whose existence is so high-level that even a child could be capable of programming them. That is, applying the philosophy of the virtual to technology, as is already done in the virtualization of work desktops or servers.
What I understand by API virtualization leads me to think of an API that really does not exist 'physically' and not an API that is a physical copy of something that exists.
What I understand by API virtualization leads me to think of an architecture that allows my source code to create an API with a perfectly defined functionality, so high-level, that we could affirm that 90% of its code does not exist and is constructed, interpreted, or compiled in real time.
What I understand by API virtualization forces me to think of a programming language oriented to the development of APIs and more specifically to the development of APIs based on a virtualized model. Why are there programming languages today oriented to specific tasks, in specific markets, but there is no programming language oriented to the development of APIs? Isn't it strange that the API world, with the value it has today in development architectures, is nourished by general-purpose programming languages, the same with which any project is developed? Would someone develop the back and front with the same language? Why do we assume to do everything related to APIs with the same general-purpose language with which we do a project?
Possibly this language does not exist today because no API manager or API gateway infrastructure manufacturer has thought of doing it, because it seems evident to me that for a language created and oriented to the creation of APIs, and for these to be virtual, requires and needs an infrastructure for publishing, governance, and exploitation of APIs according to the premises of virtualization. That is, only the language is not enough, and the appropriate infrastructure is required to support and exploit the full potential of that language.
With this, I come to two conclusions:
FIRST: I do not agree with what API virtualization represents today.
And since I do not agree…
SECOND: We have been working on a real proposal for API virtualization that we are going to share with you from 101OBEX and that, with much humility, as much as conviction, I dare to say will result in a historical milestone for the world of technology, offering the first programming language oriented to the development of virtual APIs, along with all the infrastructure to be able to publish, manage, and exploit through an API manager, the developed APIs.
Here I leave you what I believe will be the first of many more articles, as I am sure there is content for debate.
Raúl Nogales,
101OBEX CEO