What do A(G)Is and APIs have in common? Well, neither of them mean quite what they used to mean. As we said in my previous post, AI originally meant AGI, which meant designing an artificial brain. But that got watered down over time. AI came to mean whatever AI researchers researched.
An API makes programming easier, because it defines what you will get back if you make you make a request of the interface. Like AIs, APIs have been around for a long time. Back in the 1980s, AIs were usually an abstraction layer within a monolithic operating or software system.
But not all systems are monolithic. APIs turned out to be particularly helpful in computer networking, where you don’t necessarily know what’s going on in the other system. Unix guru W. Richard Stevens wrote about networking APIs in the 1990s. Those APIs would have been pretty low level, though not as low level as the device drivers.
Web APIs as we know them today arrived with the growth of HTTP–based system in the late 1990s and the emergence of SOAP (Simple Object Access Protocol) and the description of REST (Representational State Transfer) in Roy Fielding’s 2000 PhD dissertation. But APIs didn’t really move from the domain of systems programmers to that of application programmers (or even application users) until the post–Web 2.0 era from the 2000s.
APIContext is called APIContext and not Web APIContext, but that probably wouldn’t have been the case in 2010, when there wouldn’t have been much recognition of the need for a web API performance and quality monitoring tool like APIContext. So both APIs and AIs have been around for decades now. And both have changed in the way they are perceived.
But what else do they have in common?
Well, both are hot topics du jour. APIs might not get mentioned as often as AI on the business channels, but events like the Mulesoft IPO, Google’s purchase of Apigee and Cisco’s of Apptentive are hard to ignore. APIs are now the glue of the web, just as they have been the glue of software systems since the 1980s.
We live in the age of the API – and they aren’t likely to be going away anytime soon. There might be a hype bubble around APIs (having dropped $3.7 billion on Apptentive, Cisco recently declared itself an API–first company), but it’s nothing compared to the hype bubble around AI.
A(G)I is sexy – and was pretty sexy even back in the day. And like APIs, it’s not going to stop being a good idea. The difference is that A(G)I might have the potential to revolutionize the world within a decade (or two) – or it might just be another hype bubble that bursts, and 20 years from now I am still writing about how this time we aren’t living in an age of broken dreams.
APIs, on the other hand, are just a web technology. Sure, there are useful and they can be interesting and there’s a big market out there for it and a big industry that supplies the markets and there is still a lot that can be done with APIs. But they aren’t sexy.
Are there any areas of overlap between APIs and A(G)I?
Well, they are plenty of people looking into making AI services available over APIs. Something as common as a Google search is an AI application. More exciting is cognitive computing from IBM Watson and the various cloud services that offer machine learning and AI tools.
Google bought API.AI in 2016, which despite the name, is focused on natural language programming. You might be able to use Watson via an API, but the API is still going to be a traditional, rigid API. Will we ever see the application of the power of AI to the APIs themselves?
Will we ever see the AIPI – the AI Programming Interface?
To some extent, we already do have something like it. If I do an arbitrary search over the Google or Bing API, I will get something back that has some intelligence applied to it.
But the API backend has to handle what a human user sends, which is where something like API.AI might come in. (Once the NLP system works out that you want to order a 12″ pepperoni pizza with extra mushrooms, an internal API would place the order.)
However, we could argue that the API in that case isn’t really intelligent. You still need to monitor the APIs you expose and consume to see that they’re doing what they’re supposed to do, so you will still need APIContext (phew!). In fact, you might have to test the APIs more because there’s a lot more stuff that could be coming through the API. But is there more that could still be done by an AIPI?
It might be a case of parsing the freeform request into something that can be sent to a database. APIs are notoriously ticklish for a user to get working. Error messages are often opaque or non–existent. So an AIPI that provide some Clippy–like assistance with getting the security settings working or in narrowing down the exact nature of the user’s query would be useful.
A big issue with APIs is discoverability.
How does anyone know you have an API and, if they do know, how do they know what it actually does? So an AIPI could tell other AIPIs what they do, and they could also find other AIPIs out there that might be useful.
A lot of this would work on basic machine learning principles. For instance, “I am connected to these AIPIs. What other AIPIs are there out there like are these AIPIs that I might want to connect to or might want to connect to me?” AIPIs could publish their web addresses on brokerages, and then interested AIPIs could find then and make enquiries for full details of what the AIPI does, just as an experienced API engineer gets used to handling a wide variety of API–related situations, so would the AIPI. “This AIPI uses this security scheme. I have not used that before, but another AIPI that I partner with has, so I can use its experience to handle the scheme.”
And the AIPI can be self–monitoring. For instance, a standard problem we find with APIs is that they don’t always send back the correct payload. But the serving AIPI can check whether what it returned from the backend is the right thing before it sends it back to the requesting AIPI. And it can learn this dynamically in pretty much the same way as a person.
Even if the technologies I’ve described don’t seem too far–fetched, we might wonder whether we would actually want to create and use AIPIs. I think we will see.
Firstly, there is the brittleness problem.
Computer systems, and APIs, break because they’re not good at accepting unexpected input. So anything that makes them more flexible – like an AIPI – is going to helpful.
Secondly, having systems that automatically discover other similar systems is going to be helpful. Financial institutions using PSD2 APIs want to discover other institutions (and there will be thousands) using PSD2 APIs. AIPIs would help with this.
Thirdly, there’s the automation of routine tasks. The classic machine learning task is to have a large annotated dataset of inputs v. outputs, and learn to predict the output given the input. It applies to reviewing legal documents, answering call center enquiries, interpreting MRI images, translating text – and fixing API problems.
Robots and A(G)I don’t replace jobs, they replace roles. Any role that routinizes activities where there’s predictable input and output is going to be fair game for automation. And AI systems – of which AIPIs will be just one example – are only going to get better at extrapolating from small datasets, semi–supervised and unsupervised learning, and exchanging skills and knowledge between systems.
It’s going to be an interesting few years for both A(G)Is and APIs. If we think where we were five years ago much less 10 or 15, it’s exhilarating and a bit frightening to think where we might be in another five, or 10, or 15. Or in mid-January 2038…
