During an interview in 2017, I was asked if I have ever worked on an API? ’Is there someone who has not?’ seemed the apt matter-of-fact response. Because anyone who has ever written even a single line of code has knowingly or unknowingly worked on an API. So this question, without proper context, will sound very naïve.
Application Programming Interface (API)
From the era of heavy monolithic systems through the distributed landscape of early millennium, till today when everything is in process of stationing itself to cloud, APIs have stayed. Any why not, APIs fit in. Be it Object oriented principles, services oriented architecture, or decoupled microservices – at the heart of each implementation lies an API and this makes them an excellent artifact from software architecture standpoint. The use of this potential to expose an organization’s digital assets in a carefully controlled way as an API is the biggest game changer of recent times. APIs have not only enabled boundary-less partner integration but also opened doors for a lone developer to innovate and sell their innovative idea as a service on top of existing cloud platforms. With innovation in the hands of anyone who has an idea, the ability to develop, and the will to sell it – the sky is the limit.
At the onset APIs were simple. They enabled creation of big enterprise level functionalities and any feature that had the potential, to be reused and redistributed, was packaged as a library and shipped along with the product. For some this may be a shocker but yes, that is how software went live in good old days.
In the next evolution, web messaging changed things and instead of packaging the library within an application, the web communication was able to expose this library as a service. Specialized IT providers gained an ability to offer their key features over the web and if they were able to trust the party invoking this service, their feature could be reused. This enabled partner organizations to authenticate one another and share their capabilities as a service for a fee. Most commonly, it enabled IT to be centralized across different business units and smaller providers did not have to deploy their product on the customer premises, instead, could retain full ownership. This was a paradigm shift of sorts, and led to the evolution of many new technologies, for example middleware platforms and distributed operations monitoring solutions.
However, like all things amidst evolution it soon exploded into a mesh where authorizations and authentications became an administrative nightmare and in worst scenarios, an auditory compliance issue. The architecture principles evolved to answer some or all of these and a new wave of integration architecture appended itself on top of object-oriented principles.
APIs of today
Fast forward to today, APIs are back in fashion with a claim to their original name. There are no more libraries or web services but microservices. So what are the APIs of today? Not very different from the APIs of 1980s, 1990s, or 2000s, if you ask me. Metamorphically, old wine in new bottle. Still distributable, still reusable, and still very much authenticated and authorized – all over the web. What is better and smoother is the separation of interface and implementation.
The big deal is that the use cases of APIs has evolved from merely exposing a feature over the web to exposing data on the web and this is ‘sellable data’ that we are referring to. Data that is technically and legally readable. Who wants a few lines of code bundled as a feature when you can have data – Data, the new oil – haven’t we all heard! There are several commercial off the shelf products available in the market today that focus solely on API Management. Most public cloud providers offer similar services. Coupled with security features on the cloud, this is no more about reusability but about who owns the data and how can that data be reused. A popular use case is federated logins. This is helpful to service providers that do not have any option of creating a new login but force the user to key-in their social media accounts.
Last year in an API Economy learning course (the bus to the future, it said, come onboard!) I learnt that most business have a lot of legacy data and over a period of time there is a possibility that many of those organizations will transition from their original business to become an API company. Why not? It is much more profitable to sell data than to run a business. At that time, it seemed like a complex thought far ahead into the future. Thankfully, many of us do not have to dive deep into the hurdles that such a business transformation may entail. But what was clear, was that the world is still looking at APIs and they will continue to stay relevant and evolve, thanks to the thinning of interfacing layer. By the way, did you know, each service that a public cloud player provides is essentially available as an API? I will leave you with this thought and will like to hear from you about what you think of the endless possibilities that APIs bring to the table.