The New API
What are the characteristics of the API of the future?
Change is inevitable. The good news is that everything you're not good at yet will, at some point, fade away, giving room to something new. The bad news is that you need to be in a constant state of adaptation. As Philip Guston once said, "The only thing one can really learn is the capacity to be able to change." The new API doesn't look anything like the ones you're familiar with now. The new API is broader and, at the same time, more in touch with what consumers need. What are then the things that make the new API something new? Keep reading.
This article is brought to you with the help of our supporter: Speakeasy.
Speakeasy provides you with the tools to craft truly developer-friendly integration experiences for your APIs: idiomatic, strongly typed, lightweight & customizable SDKs in 8+ languages, Terraform providers & always-in-sync docs. Increase API user adoption with friction-free integrations.
When you hear the word "API," you immediately think about a technical interface that follows a set of rules: a protocol, an architectural style, a more or less strict definition, a specific format for requests and responses, a way to consume, measure, and manage, and a way to control its design and development. The purpose of all these regulations is to minimize the cost of managing change.
You want to make sure your API is as stable and consistent as possible. You want to offer the best possible alignment between your business needs and what the API consumers need. In essence, you want to offer a dependable interface that generates the best outcome for everyone involved in its creation, maintenance, and consumption.
Forget about this approach. The new API isn't anything like what you've seen so far. The more you focus on the interface, the more it becomes visible. Try blurring the interface, and you’ll realize that it’s not that important. That's how I see the API evolving. Into something that's not as important as we want it to be now. As something that's not visible at all. Something that adapts itself to the needs of both the producer and the consumers.
The new API won't follow a specific protocol. Instead, it will adapt itself—automatically, on-demand—to whatever protocols consumers prefer to use. Consumers who use the HTTP protocol will be able to use the API without hassle. Those who prefer AMQP won't feel any difficulty. The API middle-end will embrace the burden of adapting requests and responses to mold the API onto the protocols that make sense at each individual interaction.
The new API won't be restrained by any architectural style. It doesn't matter if consumers prefer REST, gRPC, GraphQL, or anything else. The API will be available simultaneously and immediately on all architectural styles. One single consumer can, for instance, make a request using a REST operation and another one using gRPC. The API adapts itself to the needs of consumers to best fulfill their demands.
The new API won't have a strict definition. Instead, its definition will be elastic. Adapted to the consumer. It doesn't matter if you use OpenAPI, AsyncAPI, or something else. Consumers will be able to use the definition type of their choice, filtered to their individual use cases. If a consumer doesn't need to see certain operations, they will be hidden from the definition.
The new API won't follow any given data format. Why should consumers have to use JSON, XML, or anything else exclusively? Consumers will engage with the API in the data format of their choice. The data format that best represents their use case. The data format that the consumer's tool of choice also uses. Integrations between systems become seamless because the input and output formats are compatible.
The new API doesn't have any consumption restrictions. Consumers can access the API from anywhere in the world with the same quality. The need for rate limiting the API doesn't exist as it can scale in an elastic fashion without much effort. Any consumer can use the tools of their choice to access the API without any limitations. Asynchronous-oriented architectures have fail-safe retry mechanisms that make message delivery seamless. API consumption effortlessly works between protocols, architectural styles, and delivery methods.
The new API is self-observable. Measuring the API doesn't require any specific configuration, frameworks, or third-party systems. Usage information flows in real time between the API and its producer. Traffic peaks, demand surges, and other interesting events are automatically handled in a gracious way. The API constantly measures itself, adapting its behavior to whatever consumers require.
The new API is easy to develop. Instead of spending time implementing the interface, developers devote their effort to translating business needs into dedicated logic. The interface layer is self-generated and adapts itself to bridge the business logic with the requests of consumers. Whenever the business logic has to change, the interface guarantees that consumers don't need to make any adaptations.
The contrast the new API creates with what we know today seems unreal. Yet, many of the characteristics I just mentioned are already available. Protocol translation gateways exist and are relatively easy to set up and use. Translating between different architectural styles is possible with something called transcoding. Offering a fluid API definition is already possible with things such as OpenAPI Overlays. And so on. It's only a matter of time until all the technologies the new API needs are available.
So, what is the role of API Design in the world of the new API? When all technological details don't need the devotion they currently have, API designers will be able to focus on what really matters. Translating consumers' needs into capabilities and then into business logic. The interface itself becomes invisible and ubiquitous at the same time.