Humanisation of APIs

The evolution of the API ecosystem

How do we begin to talk about the Humanisation of APIs and the evolution of the API ecosystem? Interestingly, the first API specification was created even before the term API was invented.

During the 1940s, the British computer scientists Maurice Wilkes and David Wheeler were working on the EDSAC (Electronic Delay Storage Automatic Calculator), an early version of the John von Neumann-inspired computer, at the University of Cambridge.

Incidentally, Wheeler is often quoted as saying “All problems in computer science can be solved by another level of indirection. A great example of indirection is the DNS system.

They were working on the modular subroutines for EDSAC, it was a pivotal time in the amazing journey of computers – when the subroutines were stored on punched paper tapes. Wilkes and Wheeler created ‘notes’ on how to use those subroutines – the first ‘specification’ of some sort, in the form of a catalogue. This specification was published in the book by Wilkes and Wheeler – “Programs for an electronic digital computer”

Two decades later, in 1968, Ira W. Cotton and Frank S. Greatorex presented the paper: “Data structures and techniques for remote computer graphics” at the AFIPS conference (American Federation of Information Processing Societies), where the term API was coined, although it meant ‘Application Program Interface’ instead of the current meaning of ‘Application Programming Interface’:

A few years later, in 1974, C J Date, whom I followed with keen interest for all the relational database work he did, published the paper: “The Relational and Network Approaches: Comparison of the Application Programming Interface”

And the term API with its current form “Application Programming Interface” saw the light of the day, although in this paper it was in the context of relational databases. A decade-and-a-half later, in 1990, the more general definition of API was introduced by the Author and Technologist Carl Malamud as, “… a set of services available to a programmer for performing certain tasks”. The API revolution was started, fuelled by many frequent events and it continues to date.

So, what are APIs?

An API is a language – a language that machines use to talk to each other to request services, a special mechanised language, and as any other language – it is a contract, it is a common understanding established between technical platforms to interact with each other.

It is the API revolution; here’s a staggering statistic – Akamai reported that 83% of all web traffic comes from some form of API. As per ProgrammableWeb, there are more than 24,000 public APIs listed in their directory, there are many more private APIs existing in the digital world making a significant impact on the overall technological acceleration we see today.

Statista reported in 2020 that developers spend 30% of their time coding APIs of some form – interestingly, this is almost double the time they spend in debugging the code, clocking in at 17%, which is the second most time-consuming task for the developers.

The APIs have gone through several evolutions, from SOAP-based APIs to RESTful (I still remember the heated and emotional debates on SOAP vs RESTful while working on large-scale API exposure systems for Telecoms), and from service-oriented APIs to data-oriented.

As with everything else in the digital world, APIs are evolving, and I can see a specific trend, which is in synergy with the rest of the digital world and broadly with the technological world. Here is what I see as the evolution of APIs so far, especially for APIs in the context of digital identity, although this applies generally to any other domain as well:

Siloed – Vertical APIs:

This is a service-based approach, where each of the services has a set of APIs, either structured through “resources” to follow a RESTful model or a specific API per service.

Singular – Horizontal APIs:

A convergence of APIs into a singularity – a single API across services irrespective of geography and functionality, a singularity across space and time (the API remains the same across availability and coverage and does not change for future products and coverage)

Convergent – across device and server-initiated APIs:

Most APIs are positioned between servers, initiated by the API consumer’s server and fulfilled by the server of the API provider. There are some APIs which are initiated by devices due to the functional boundaries, e.g., Mobile Authentication APIs – which need the mobile device to interact with the mobile network.

Earlier, the server-initiated and device-initiated APIs were two separate entities, and now – as with everything else – there is a convergence on the horizon – converging the device and server-initiated APIs as much as practically feasible and adding in the device-initiated part as a logical extension.

BYOA – Bring Your Own API:

The API as a language and the technical contract have been one-sided for most of the time it has existed – it is defined and enforced by the provider of the API, and in a way, this makes sense. If we now bring in the business expectations and customer centricity, in certain situations, why can’t we have the API consumer expect the API or at least some part of it to be defined by the API consumer?

This is an interesting aspect of the evolution of the APIs, to break the inertia of the one-sidedness of the API ecosystem and allow the API consumers to bring in their own API definitions – at least part of it – under certain conditions and constraints.

Humanisation of APIs – Natural language-based APIs:

Humanisation of APIs – The evolution of the API ecosystem; this is the ultimate convergence, and my favourite one; the convergence of the language of the machines and the language of humans. With the advancement of Generative AI and large language models like GPT-3 from OpenAI with 175 billion parameters and the much-anticipated GPT-4 with a staggering 100 trillion parameters, these technologies are making it all possible.

The incredibly popular ChatGPT application utilising GPT-3.5 from OpenAI has already shown the art of the possible and has raised the expectations – not to mention widespread media coverage – of the masses. This will go beyond the discussions of the one-sidedness of API definitions or what API specifications should be used as APIs will be accessed using natural languages.

Generative AI and large language models will make machines use the same natural language as humans – Humanising the APIs and redefining the ultimate singularity.

At Sekura, the SAFr APIs are at the ultimate edge of the API evolution and leading the way to make the world a SAFr place.

The future is magical, the future is now.

With coverage across 5 continents, Sekura Mobile Intelligence is the leading global provider of mobile identity solutions, providing trusted, secure, and easy-to-consume solutions for ID verification, anti-fraud and secure online authentication use cases. Sekura works with established KYC, identity verification and risk data providers who have already integrated into leading global brands with demand for mobile identity solutions.

Through the integration of real-time mobile data into our partners’ existing services, we enable them to extend and enhance their customer offerings into new services, use cases and geographies through the adoption of SAFr, our single standards-based, mobile intelligence API.

To offer your customers the opportunity to benefit from our global mobile identity solutions, contact the Sekura team today.