Three Predictions for 2024 API Futures

Now is the time of year to offer predictions and oraculations on the future state of the API space and I, for one, am happy to pile on. This post is part of APIFutures, a community-led, collaborative effort to identify the top challenges and opportunities facing the API economy in 2024. For other perspectives, be sure to read the articles by other excellent authors, consultants, and technologists listed here.

Greetings My Friends …

Before I dive in to my predictions, let's first hear from The Amazing Criswell, a noted psychic from the middle 20th century as he explains (in his typical sonorous tones) why we are all interested in the future (click the image to play the short video) :

In the Future, APIs will …

Rather than try to predict the near term future of APIs (e.g. changes in the upcoming year), I'll use this opportunity to talk about what I see as larger trends and achievements that we all can focus upon over the next several years. Basically, this is where I see us headed both in terms of wants ("here's cool new technology") and needs ("so, when will someone finally solve this problem?"). 

As Criswell warns: "future events such as these will affect us in the future."

So, here we go.

Connect to services the way we currently connect to servers

We've gotten very good at connecting to servers using DNS as a "glue" that hides physical location and even abstracts the notion of a server via clustering technology. This has made it super simple to not only make connections to servers but to maintain those connections even when the physical details have been modified. 

For example, the actual machine that answers to a name (e.g. www.example.com) might be in New York today and be moved to Singapore tomorrow. And when that happens no one needs to update their code in order to connect to that machine. This is also true when the machine in Singapore has been placed in a round-robin cluster of machines that all answer to the same name. 

On the network, "machine" is an abstract concept.

This is not always true for services and APIs. Most all the definitions and descriptions we share are concrete, not abstract.  If a service (www.example.com/services/customer) is moved from one location to another, it often gets a new address (www.example.com/customer-service). This type of change will usually require updates by someone, somewhere (at the API consumer, API gateway, etc.). It can greatly limit the way services can be improved over time and increases the cost/risk of change, too.

On the network, "service" is a concrete concept.

There are already companies that are working to solve this problem. One of the more promising is Superface.ai. Their solution is to eliminate the cost/risk of these types of changes by creating "smarter" clients and gateways through what they call "Self-Integration." Their solution is influenced by a straw-man protocol design I published in 2019 called "Open Disco". Both of these solutions rely on publishing additional service metadata as outlined in the APIs.json specification. 

By creating runtime catalogs of available services along with the detailed metadata about those services, clients and gateways can find and negotiate, at run time, connections to service providers without the need for changes in code or configuration on either the API consumer or the API producer.

I predict we'll see more advancements in the area of API cataloging at design time and API discovery at run time; all leading to a more reliable and resilient API/service fabric.

Program the network instead of single machines

A reliable service fabric is essential to solving another important problem in the API space: programming at the proper abstraction level. Most of the time, developers are led to design, program, and test on a single machine (real or virtual). The results are then published as the service host for others to use directly -- often also using a single machine or single cluster (see above).  This is fine if you want a single client code-base to interact with just one machine in order to solve all its needs. But the last ten years have shown us that most APIs are used, not as a single-source stand-alone solution but as a way to enhance the select functionality of a client application. Think messaging, tax computation, scheduling shipments, and other specializations.

Think about creating a customer management solution for your company. This usually means designing and building a monolithic host service that handles all the details of the customer management domain. This includes things like security, data management, scaling, and event notification and more. This despite the fact that there are lots of stand-alone services to handle these individual tasks. 

But, we don't need to take on all that work ourselves. We can use a separate service for user authentication, one for sending SMS and other notifications, remotely connect to data storage, and distribute content across the globe to improve scaling and reliability. 

However, most solution-building tools (GUI Editors, command-line tooling, etc.) makes creating an integrated solution like this difficult to build and challenging to test and release. Instead, each working solution ends up as a one-off, custom-built large-scale project that becomes brittle over time and is overly dependent on remote providers who can change interfaces and discontinue services over time.

A more robust solution is one that treats all services as abstract external interfaces and reduces the need for one-to-one integration work. These shared interfaces at the domain level are growing in number and functionality well beyond the low-level tasks of security, messaging, and data storage, too. For example, we're seeing high-level domain-specific solutions with BIAN and Open Banking for finance, HL7 FHIR for health services, ACORD for insurance, and many others. On a more generic front, projects such as Jeff Michaud’s HCLI and my own HyperLANG are examples of programming environments that suport the Web itself as the target domain.

Whether targeting low-level service interfaces such as alert notifications, broad domains like banking and health care, or simply a high-level interoperability languages that work at the web level across individual implementations, the ability to create shared understanding across protocols and formats can reduce the risk/cost of creating interoperable services as well as improve the likelihood that solution providers will be able to intermix services from multiple vendors more safely and easily.

I predict we'll see continued interest and growth in standardizing domain-specific interfaces and that will  accelerate the use of multi-provider API solutions.

Describe problem spaces, not solutions

Along with the abstraction of machines and the rise of standardized domain-specific interfaces, I see a shift in the way network programming languages are designed and implemented for network-based solutions. Today, most of the often-used programming languages we see are very general (C family, Java, Python, Ruby, etc.). Aside from minor differences in optimizing memory, safety, and other important features. programming languages today are interchangeable. And, for the most part, programming languages are used to describe the solution to a predefined problem (what's the best way to store this data?, compute this total?, interact with humans to collect search criteria?). Most programming languages used today are imperative. 

Alternatively, declarative languages like SQL, Erlang, and Lisp have been around for quite a while. And the rise of the internet over the last 25+ years saw a surge in the popularity of declarative programming languages like HTML, CSS, and XML. There has even been efforts to add declarative support to the JSON format with schema, pointers, and path implementations. Can a declarative transformation language for JSON be far behind?

One segment of the API space that has embraced declarative solutions in the last ten years is DevOps. We can see this in languages like Puppet, Terraform, Ansible, and others. With these languages, developers detail the desired end-state of a deployment and can rely on platforms to figure out what needs to be done (installed, updated, configured) in order to reach that described state.

There are already some examples of declarative programming in the API space. For example, linting tools like Spectral can be used to describe the end-state of an OpenAPI document using rules. OpenAPI, AsyncAPI and related formats are all examples of  design-time declarative languages. In 2015 I was part of a small group of people who defined a cross-protocol declarative API specification language called ALPS that continues to have a small dedicated following.

Of course, no API prediction post would be complete if it didn’t make a reference to the stochastic parrot in the room. In the last year, a very different kind of declarative programming has become popular. It goes by the name of "prompt engineering" for AI platforms. Although programming generative AI is still in the early stages, it seems inevitable that more and more people will be writing code (and prose) meant for AI consumption and for producing results.

I predict we'll see more examples of declarative programming of APIs in our future as the need to solve more complex problems increases.

Where we will all spend the rest of our lives

The recorded history of APIs on the web is already more than  twenty years old and a lot has changed since Salesforce and eBay published those first APIs for web developers. We've created lots of tools, built tens of thousands of APIs with those tools, and those APIs have supported millions of users around the world. 

We all have an opportunity to improve the quality of APIs as well as the status and standing of both users and developers in the space. Making API programming more resilient via catalogs and runtime discovery, creating standardized interfaces that we can all rely upon in the long term, and creating more declarative platforms as the API space grows in complexity and reach are all excellent ways to build a better future for everyone.

As The Amazing Criswell points out in the opening video, "We are all interested in the future because that is where we will spend the rest of our lives."  One way or the other, we will all be living with the APIs of the future and it is in our best interest to design, build, and promote a healthy, equitable, and sustainable version of that future.

So long for now. See you next time in ….

The Future!

REMINDER
This post is part of APIFutures, a community-led, collaborative effort to identify the top challenges and opportunities facing the API economy in 2024. For other perspectives, be sure to read the articles by other excellent authors, consultants, and technologists listed here.