See what makes Kong the fastest, most-adopted API gateway
Check out the latest Kong feature releases and updates
Single platform for SaaS end-to-end connectivity
Enterprise service mesh based on Kuma and Envoy
Collaborative API design platform
How to Scale High-Performance APIs and Microservices
Call for speakers & sponsors, Kong API Summit 2023!
10 MIN READ
We live in a digital economy where Application Programming Interfaces (APIs) are foundational elements for businesses to operate and grow. As rightly outlined by Gartner, APIs interconnect individual systems that contain data about people, businesses and things, enable transactions, and create new products/services and business models.
The popularity of APIs has grown significantly in the last decade or so, but the history of APIs stretches back much further. (Check out our eBooks on the evolution of APIs and APIs in the cloud age for a deeper dive on this subject.)
Cloud computing has revolutionized API development and deployment. Cloud vendors offer various cloud services through API endpoints. These API endpoints can be accessed through the browser, command-line interface (CLI) tools and SDKs.
The future of software is distributed. With most organizations on the planet on some sort of cloud journey, the desire to accelerate the path to rapid, cost-effective innovation cycles is driving them all the consider the best of what the cloud platforms have to offer.
This “polycloud” approach to innovation lifecycle results in complete applications, which once resided in a single cloud platform of choice, now spanning multiple (and sometimes all) public cloud platforms.
The benefits of a polycloud approach include the ability to take advantage of the best-of-breed capabilities across the cloud platforms. Polycloud also allows organizations to embrace a broader set of developers, skills, languages, and tools to deliver better digital outcomes.
Docker and Kubernetes are good examples of technologies that made the move to — and across — polycloud incredibly easy and low risk.
Polycloud is not without its challenges, however. One aspect that can be more difficult in the process with polycloud is consistency in terms of discoverability, management, security, and governance across what is a quite distributed IT substrate.
Kong helps organizations accelerating their cloud journey, and embracing polycloud footprints to stitch together, manage, secure, and make observable the numerous application components that comprise these new distributed applications. This happens across APIs controlling access into, out of, and between these applications, as well as the microservices from which they’re comprised. Broad service connectivity becomes the fabric allowing the future of software to remain distributed, but doing so in a secure and easy to manage and control fashion.
In the cloud age, the most common architectures for APIs are RESTful APIs, gRPC and GraphQL. We will discuss each of these API types in brief in the sections below.
Representational State Transfer (REST) arrived over 20 years ago and was broadly adopted by developers who found SOAP cumbersome to use. APIs that adhere to REST are known as RESTful APIs. To be RESTful, an API adheres to the following requirements:
Figure: Layered system
Although RESTful APIs support multiple message formats (such as HTML, YAML and XML), RESTful APIs predominantly use JSON documents, which are a series of sections with key-value pairs.
OpenAPI is a formal specification for how to define the structure and syntax of a RESTful API. This interface-describing document is both human and machine-readable, which yields the following benefits:
Google introduced another framework for APIs called gRPC, which uses HTTP/2. A gRPC client can directly call a service method on a gRPC server. The gRPC server implements the service interface—consisting of its methods and parameters and the returned data types—and answers client calls.
In the “The Evolution of APIs: From RPC to SOAP and XML” eBook, we discussed how Remote Procedure Call (RPC) was one of the earliest means of communication between applications running on remote machines. gRPC is a framework for creating RPC-based APIs. gRPC is based on RPC but takes it a step further by adding interoperability with HTTP/2.
Compared to RESTful APIs, gRPC has benefits that include smaller messages sizes, faster communication and streaming connections (client-side, server-side and bidirectional).
GraphQL is a query language and runtime that allows users to query APIs to return the exact data they need. With a RESTful API, clients make multiple calls for data with different parameters appended to the URL. In contrast, GraphQL allows developers to create queries that can fetch all the data needed from multiple sources in a single call.
With APIs functioning as standalone pieces of software not dependent on the rest of the application’s functionality, APIs evolved toward loosely coupled design. This approach ensured API services could be redesigned, rewritten and redeployed without running the risk of breaking other services. Strategies for making an API service loosely coupled include:
Figure: Two Loosely Coupled APIs Using Message Queues
Microservices allow a complex application to be broken down into small, independent “services.” Microservices can be written in any language and deployed anywhere, and their functionalities are exposed as APIs. Callers of those APIs might be end-user clients or even other microservices.
Figure: Example of a Microservice Architecture
What makes microservices unique is that they are loosely coupled and independent. In other words, you can change the program code and internal workings of an API within a microservice without touching the entire application. Like APIs, microservices can be written in any language and deployed anywhere. Because microservices are loosely coupled, a single microservice experiencing a spike in load or a failure won’t bring down the entire application.
A serverless function is a standalone piece of code that a cloud provider runs on its managed environment, such that the customer (the developer) does not have to worry about infrastructure or scaling. As far as the developer is concerned, there’s no server involved—it’s serverless.
An application can comprise microservices running on physical machines, virtual servers both on-premise and in the cloud, Docker containers running in Kubernetes pods, or as serverless entities. To communicate with one another, these microservices might connect using direct links, VPNs and trusted virtual private clouds (VPCs) at a physical level. To manage the complexities of network performance, discoverability and connectivity, we have the service mesh.
A service mesh is a dedicated infrastructure layer built into an application to enable its microservices to communicate using proxies. A service mesh takes the service-to-service communication logic from the microservice’s code and moves it to its network proxy.
The proxy runs in the same infrastructure layer as the service and handles the message routing to other services. This proxy is often called a sidecar because it runs side-by-side with service. The interconnected sidecar proxies from many microservices create the mesh.
Figure: A Service Mesh Running on Hybrid Cloud
The service mesh offers many advantages to microservices, including observability, secure connections and automated failover.
The cloud age introduced the idea of an “API economy” — or the business practice of organizations exposing their digital services or information through the controlled use of APIs.
While the API economy looks attractive today, we believe it will become even stronger in the future. According to Gartner, by 2023, 65% of global infrastructure service providers’ revenue will be generated through services enabled by APIs, up from 15% in 2018. Over the last 10 years, APIs have played a significant role in the growth of fintech, artificial intelligence (AI), blockchain, Internet of Things (IoT) and cybersecurity.
Web 3.0 (originally called the “Semantic Web” by Tim Berners-Lee) is the web that will dominate tomorrow. It’s envisioned that Web 3.0 will be based on decentralized networks and protocols. A website will never go down because a chain of servers will serve it. In Web 3.0, blockchain will become ubiquitous, with no single authority of an entity over information.
The web we know today will become more accessible than ever, by smart devices that are internet-ready and can search, consume, process and share information just like phones and laptops do today.
Searching, consuming and sharing information and content will be based on semantics (meanings) rather than exact keywords, making Web 3.0 heavily dependent on AI to understand and predict the intentions of humans.
How will APIs look in Web 3.0? Most likely, APIs will be event-driven.
The traditional approach to consuming an API has been request-response. Applications send an API query, and the API sends back a result.
Figure: Traditional API Access with Request and Response
In Web 3.0, event-driven APIs will send data when an event occurs. A consumer subscribes to an API endpoint, indicating that it wishes to receive updates asynchronously when particular events happen. When a matching event happens, the API sends the event’s data to all subscribed consumers.
Figure: Event-Driven API with Event Push
There are several approaches to building event-driven APIs, and they include webhooks, WebSocket and Server-sent events (SSE).
Blockchain is a distributed ledger of transactions based on trust and verification. Each transaction in the blockchain is immutable and is open to all nodes in the network.
APIs are making a huge impact in smart contracts, which are applications stored in a blockchain that run to enforce the agreement of a transaction in real-time. The agreement can be anything from exchanging information to e-commerce purchases.
At times, the smart contract needs to access data and functionality outside the blockchain. Ledgers use a blockchain oracle to query, verify and authenticate external data sources, but this could be a single point of failure. In the future, smart APIs running within the blockchain could be a possibility.
Cloud providers now offer several advanced AI-enabled APIs for developing cognitive applications like natural language processing (NLP), face recognition and video analysis. Using these services’ APIs significantly reduces development time as the cloud product does most of the heavy lifting.
AI can also be used for automated documentation of APIs and monitoring of API security threats or optimization opportunities.
APIs for Internet-of-Things (IoT) are the glue that sits between heterogeneous devices and the applications that use them. Typical examples of IoT APIs can be seen in app-controlled devices like personal fitness trackers, lights, alarms and more. These devices capture information and send that over the internet to the manufacturer’s backend system.
What are some areas in which the development community ought to prepare for the next big change in the world of APIs?
Kong is well suited in all of the above areas. Kong doesn’t hold organizations back from embracing APIs in the cloud age.
As the world’s most popular API Gateway, Kong is flexible to run in nearly any environment or architecture a project requires. Both configuration and deployment of Kong support automation with common CI/CD tooling, thus enabling the all-important speed in development, scaling, and recovery.
Automation and elasticity as demand for APIs ebbs and flows. Independent form scaling is raw performance, expressed in latency, and throughput. Once again Kong does very well here.
While the merits of APIs remain unchanged in the cloud age, the tooling for APIs must be cloud native. This is one of the reasons Kong is superior versus legacy tools like Mulesoft. See how Kong delivers more speed, scale, and value in GigaOM’s report on Kong vs Mulesoft Anypoint Platform.
Talk to one of Kong’s API experts to learn more about tapping into API-driven innovation.
Share Post
Download our Free Evolution of APIs e-Book
Download Now
Learn how to make your API strategy a competitive advantage.