Machine-to-Machine Challenges (AGI/ANI)
While handling APIs using AGI is not feasible at this time, employing an ANI approach can lead to very powerful M2M APIs
Our brains are amazing. So amazing that we often don't even notice how much "magic" they are doing for us.
Brain Scans
A fine example of this can be seen in the act of filling in a simple HTML form (like the below).
Once our eyes scan the page (magical enough!), our brain needs to handle quite a few things:
Recognize there is a FORM that can be filled in and submitted
Work out that there are four inputs to supply
Recognize the meaning of givenName and the other identifiers
Scour our memory or some other source to find values that correspond to these identifiers to fill in all the inputs
Know that one needs to press the Submit button in order to send the data to the server for processing
We also need to be able to deal with things like error messages if we don't fill in all the inputs (or do that work incorrectly), and any response from the server such as "unable to save data" or some other strings that might require the agent to take further action.
H2M and M2M
When we write human-to-machine (H2M) API clients, we can just assume that all that mental sophistication is available to the client application "for free"—we don't need to program it in at all since the human brain will handle all that.
However, for machine-to-machine (M2M) applications, that "free" intelligence is missing. Instead we need to either build the power of a human into our app, or come up with a way to make the interactions work without the need for a human mind running within the application.
AGI and ANI
If you want to spend your time programming machine learning and artificial intelligence, you can take option one. This is typically characterized as artificial general intelligence (AGI). Essentially you're relying on someone (or yourself) to program an agent that will take the same responsibilities as a human would in your API interactions. You take out the human, and replace them with an AGI bot. To date, there are no affordable, scalable, consistent widely-available AGI bots that can reliably replace humans for API work.
However, there are lots of examples of artificial narrow intelligence (ANI). IN the case of an ANI bot, they are designed to be successful within a limited vocabulary. The set of variables and actions they recognized are narrowed to a small, reliable collection. While this limits the range of possible problems to solve, it increases the likelihood of success in solving problems the bot recognizes.
HTTP is ideal for ANI protocol
While AGI is still unreliable at scale, ANI has an ideal home in the world of HTTP protocol. HTTP was designed to have a constrained vocabulary (with optional extensions). This makes it possible to enlist both services and client agents into scalable interactions within the same narrow vocabulary.
We can do this by leaning on media types to handle things like knowing ahead of time all the general tasks of HTTP communications protocol (messages, headers, and methods). We can also program client agents ahead of time to handle message body content such as FORM and its metadata. We can also leverage semantic profiles as a way of dealing with the variables that might appear within a FORM and how to associate these parameters with locally (client-side) available data to fill in the parameter values.
While handling APIs using AGI is not feasible at this time, employing an ANI approach using predefined protocols, registered message formats, and closed vocabularies can lead to a very powerful set of M2M interaction possibilities for your APIs.