Forem: Z

AI in APIs

Wed, 16 Nov 2022 12:08:13 +0000

Artificial Intelligence (AI) is making its way into everyday developer life, but the use of AI along the API lifecycle is yet to be improved. For decades APIs have relied on tedious manual work. Tasks like API design, API documentation, discovery, contract, and API integration are primarily manual, but a change is coming.

APIs can leverage AI, and AI can significantly benefit from APIs. Though the use of AI in APIs is a vast topic, we will split it into two. The first is employing AI (precisely ML – machine learning algorithms) to deliver or integrate APIs. The second topic is enabling AI, which can either mean making AI accessible via APIs or making the APIs accessible to an AI.

Using AI in APIs

Using AI/ML can enhance a developer's life, boost efficiency, and lead to better applications and shorter delivery times. Following are a few examples of employing AI in APIs delivery and consumption.

AI client and server code-gen

The most straightforward use of AI/ML is to generate API calls or server code on behalf of a programmer. Solutions like GitHub Copilot can create code stubs, reducing developers' need to write the API calls boilerplate. As a larger corpus of API calls is needed, this approach is primarily suitable for public APIs.

API client code generation with GitHub Copilot

AI API design

A good API design is a function of developer experience and operational efficiency. Algorithm-guided API design can improve the efficient layout of resources. Traffic recording and profiling information from API observability tools (Akita, Optic, Seekret, …) already provide valuable insights and can be the input for the AI-guided API design.

AI can also aid in designing APIs from the ground up, mapping the use cases into correct API protocol/style semantics. For example, from the operation name "make payment," the algorithm may infer an unsafe, idempotent operation and, therefore, the POST HTTP method.

Jurrasic-X assists in mapping a use case to an HTTP method

AI API integration

The opposite approach to AI-guided API design is that an algorithm can infer what operation to invoke, what the parameters are, and how to map them from the user input to the expected result. These algorithms can take a business case for an API (e.g., "how to fulfill an order") and API documentation as input and figure out the required API communication to complete the use case.

OpenAI GPT-3 aiding with API integration

AI API security

Currently, the most mature area is using AI/ML algorithms to analyze valuable information from the API traffic. For example, an algorithm can check whether there are sensitive data in the traffic or when a malicious communication pattern threatens your systems. The existing tools (Traceable, Aiculus) already help security, DevOps, and compliance teams in their work.

Levels of enabling AI

Beyond helping developers deliver or consume APIs, AI can greatly benefit from them. Here's how APIs will gradually enable AI.

1. APIs as the interface to AI

APIs are vital in making AI and its infrastructure accessible to other applications. Many AI/ML models and algorithms are proprietary (OpenAI) or resource-consuming, so they can't be self-hosted by their users. API is the standard way to make AI available in these cases. The same applies to AI/ML and data science infrastructure (Google, Azure, AWS), where users can develop and run their models.

2. Self-integrating applications

Self-integrating applications are the revolutionary step in distributed systems. It enables applications to integrate without the need for human intervention. This integration can be direct between two applications or via an intermediary – an integration platform.

Advanced integration platforms can infer common integration patterns, and when a new application enters the organizational landscape, it can be automatically hooked into the existing applications.

Several integration platforms already employ algorithms to assist engineers in their repetitive tasks of data mapping and system integrations (Dell Boomi, Snaplogic). Still, we need the new infrastructure to enable applications to integrate without assistance.

Superface is the pioneer in direct self-integrating applications, enabling them to integrate autonomously without needing an intermediary.

3. Autonomous applications

An autonomous application can navigate and make decisions in its landscape. Unlike a self-integrating application, an autonomous application can decide which API to connect and when.

The critical difference to the present API clients is that the autonomous applications are programmed for a job, not how the job is executed with a particular API at a given time.

To illustrate, a manufacturing application can be programmed to check the status of the works on the product. However, it is not instructed on how to do it and what APIs to ask. Instead, when executed within a landscape, the application will determine what APIs are available and which ones to call to get the answer.

Autonomous application conceptual scheme

4. Autonomous Business Integrations

Autonomous business integrations take the concept of autonomous application to the next level. The application can discover and connect to an API without human intervention, but it can also enter a business contract on its user's behalf. The autonomous business integrations (ABI) will fully unlock the digital business-making where software can evaluate, enter or fulfill contracts.

An example would be a commerce application that needs to send text messages to its users in various countries. At any given time, such an application can quickly evaluate all available API providers, their costs and quality, make the purchase, and send the messages at the best price and quality.

5. AI applications

The pinnacle of interfaces for AI is a system where the tasks are not hard-coded in the application. Instead, the application can infer (e.g., for a user's input) what job to execute, the available APIs in its landscape to fulfill the task, and which one to use. This ultimate step will unlock the reasoning AI that would be able to navigate in the universe of humanity's capabilities.

But if the technological Singularity can happen, it will.

– Vernor Vinge

At Superface.ai, we are committed to researching and advancing AI in APIs. We have released the infrastructure for self-integrating applications and are heading forward to introducing the autonomous business integrations and, at a later stage, towards the AI systems.

If you are working in one of the areas, or you think I've missed one, let me know in comments!

Stop the manual API plumbing

Fri, 25 Mar 2022 13:42:30 +0000

APIs rely upon bespoke, manual, and tedious work. Typical time sinks are poor documentation, undocumented behavior, non-standard API design, custom authentication schemes, unclear limits, and terms of service. Yet, the real pain comes later when APIs change. Once you lay down the wires, you are in the business of perpetual maintenance. Sure, you can close your eyes and pray, but APIs are a dependency and, potentially, a liability. But it doesn't have to be.

Most of us want to get to the value delivered over APIs quickly. Chances are you don't care whatever was the fancy API style in 1998. Besides, it will be different with the very next API you need to connect. So why bother?

Use-case abstraction

The solution lies in the use-case level abstraction on top of APIs. The concept is simple. If you are an API consumer, integrate with the use-case, not with a provider: “Send text message” vs. POST https://api.twilio.com/:version/messages.json. If you are a provider, publish your business capabilities: “Make a payment with PayPal” vs. customerPaymentMethodPaypalBillingAgreementCreate(billingAgreementId: $billingAgreementId, customerId: $customerId) (source). The technicalities of the connection can be dealt with autonomously with the right metadata.

Hexagonal architecture

The implications of use-case abstraction are profound. The clean, hexagonal architecture results in decoupling client and server and
enables independent evolution, breaks technical vendor locks, speeds up the development, and radically reduces maintenance.

To learn about the use-case abstraction for APIs, check out Superface GitHub profile.

OpenAPI cures the symptoms, not the disease

Thu, 24 Mar 2022 14:35:59 +0000

At Apiary.io, we were promising to solve one immense pain for developers: API documentation. The pain was so big that developers would rather learn API Blueprint or Swagger (now OpenAPI) instead of writing documentation by themselves. It has turned out developers need more than a reference of the endpoints to build a successful API, something we could never deliver generating documentation from a specification.

We failed the mission because we were not fixing the root cause: APIs need engineers to integrate APIs. And now, we are still just serving painkillers with OpenAPI to cover up the symptoms.

Yes, having a reference is better than an undocumented API. Everywhere where API client self-service matters, additional documentation is needed. But no developer wants to write it. And if someone does, a new extensive problem arrives: How do you keep the documentation in sync with reality?

Tools

So we have built tools. We built testing tools like Dredd to test API description and its API implementation. Mock services for quick prototyping. Interactive documentation for developers to play with the API because the documentation itself is not enough to explain the API clearly. We incorporate all these tools in the pinnacle of "humans connecting the software" – the developer portals.

And we have built more tools. Because we have not dealt with the core of the problem, we created even more pain points. We looked at our designs and said: Oh, you can’t publish the API because it has a poor design! All the company APIs must look alike because it is easier for human developers to comprehend and connect. So the API guidelines and tools like Spectral were born.

Painkillers, not the solution

We keep covering up the symptoms, but we create more problems in the process. I have contributed to all these concepts both as the author of API Blueprint and later as a consultant. And though we left the world in a better place, these tools will not take us much further. What we are doing is not working.

To move ahead, we need to solve the root cause of the problem. We must stop having people writing API documentation so other people can find it on Google (or internal catalogs) only to bake whatever is in the docs to their software. And when they do, they need to eyeball the documentation as long as they want their integration to work. This might work for software libraries but not for distributed systems.

The Cure

So what is the solution? Autonomous APIs. Self-integrating applications. A distributed infrastructure where applications can meet, enter into a contract, and connect based on how they are programmed without knowing each other's implementation details.

Autonomous systems will replace client-facing documentation. They will minimize the time needed for integration, nullify the maintenance, and massively reduce client and server codebases. The API design will be only a matter of performance, not a tool to attract (or not to lose) client developers. Oh, and those annoying API integration tests and invasive integration platforms? They will go away too! We do not need proxy platforms to connect if our application can self-integrate!

Let’s fight the disease!