Application Programming Interface (API) is a type of interface that enables interactions. Different from the User Interface (UI) that enables interactions between users and applications, API enables interactions between applications. Over the past 20 years, API has grown from an abstract concept to a big family in production. In this article, we’ll go through the journey of API from three different aspects, i.e. Components of API, Types of API and Future of API.
Components of API
The API interactions involve three components: API provider, API consumer and channel. The API providers define interfaces, the API consumers consume the interfaces, and the channel connects them together. The evolvement of these components have been driving the development and developing pace of API. We’ll take a quick look at a few milestones of the evolvements, which will help us understand how API have journeyed through to today’s state.
- API Provider
The pioneers of API providers came from the commerce sector, being Salesforce, eBay and Amazon. They published their API back in early 2000s. The other players from social and cloud sectors joined afterwards, like Facebook, Twitter and Google. After 20 years, these names still remain strong. It proves that they’ve done things right, and API is definitely one of them. - API Consumer
Even the big players had put on their API-provider hat in early 2000s, the development pace of API was still not eye-caching. A bit like the “One hand can’t clap” situation. The API consumer side needs a stimulation make the sound louder. And the game changer event happened in June 2009, the launch of iPhone together with iTunes. The mobile applications started to join the application family. It directly boosted the IT industry to a new era, and widened the runway for API.
In case you are thinking why we use terms like consumer-provider instead of client-server, the reason behind it is another IT industry evolution, i.e. the serverless framework. In many cases, especially in the cloud, the serverless framework has replaced the traditional on-prem and IaaS servers. If there are no servers, then the client-server term won’t be applicable anymore. So we are using more generic terms, i.e. API providers and consumers. - Channel
With both API provider and consumer in place, the channel between these two parties was also going through the evolution, e.g. the World Wide Web (WWW), the Internet and the evolution of Web 1.0 to 2.0, which have added fuel to the fire. We’ll take a look at a few popular types of APIs and when they jumped on the runway in the Types of API section below.
Types of API
There are many ways to classify the types of APIs. We’ll go through the API types from two different angles, i.e. protocol and architecture. And we’ll go through a few popular APIs (as shown in the diagram below) based on these two API types.
Type by Protocol
When it comes to protocol, it’s like human language. It defines rules, syntax and semantics to enable communications between two parties. There are quite a number of different API protocols defined under various release policies. It’s hard to cover all of them in one article. So we’ll talk about a number of most well-known API protocols below:
- XML-RPC
XML-RPC, published in 1998, has two key elements. It follows the Remote Procedure Call (RPC) pattern and uses the XML format to transfer data. RPC in a nutshell is a consumer-provider interaction. The API consumer remotely calls for a procedure to be executed at the API provider side. The API provider then returns the execution result back to the API consumer. The calling and responding message are both in XML format. It makes XML-RPC pretty self-explanatory.
Following this pattern, another example is JSON-RPC where the messages are encoded in JSON. It came in 2005 and enriched the language options for RPC. Subsequently, gRPC (2016) expanded the encoding options further by adding the Protocol Buffers. - SOAP
Simple Object Access Protocol (SOAP), published in 1999, is also an XML based protocol that uses the RPC pattern. We can consider that SOAP evolves from XML-RPC. The new concept (at that time) SOAP introduced was Data Encapsulation. In other words, putting data in an “envelope”. The envelop contains header and body blocks. The header defines how to interpret and process the the body, and the body contains the actual message data.
In addition to the envelope structure, SOAP also introduced a set of encoding rules and a convention for procedure calls and responses. This informative protocol provided a good standard for the industry at that time. It suits well when there were mainly big players in the API market with waterfall type of developments. However, when more small players joined the market with agile type of developments, this verbose protocol became an overhead.
Type by Architecture
From the architecture aspect, there are two common API architectural types, provider-driven (e.g. REST API) and consumer-driven (e.g. GraphQL API). We will go through them below.
- REST API
Even REST is classified as an API architecture instead of a protocol, it was created to address the problems of SOAP. As we mentioned earlier, SOAP is informative and verbose at the same time. When everyone are new to the game, well-defined rules can help users go through the learning curve. But once everyone are familiar with the game, these verbose rules become an overhead. Players would seek more effective way to play and evolve the game. So back in 2000, REST was born.
The REST was born with a mission to simply API but retain a core set of principles and constraints. The way how REST was defined is like an minimum viable architectural guidance for building a house. For example, it specifies that a house must have a bathroom and a kitchen. But it doesn’t intervene how developers design and build the bathroom and the kitchen.
Roy Fielding defined the REST in his 2000 PhD dissertation. The way how he defined the core set of principles of the REST can be summarised as:
– Uniform Interface
– Client-Server Architecture
– Statelessness
– Cacheablility
– Layered System
– Code-on-demand
If you are interested in knowing more information about these principles, see REST API Architectural Constraints.
- GraphQL API
REST API has addressed the pain points of SOAP, but it has its own disadvantages, e.g. over and under fetching data. So Facebook developed GraphQL API to address the shortcomings of REST and released it in 2015.
The way how GraphQL addresses the most pain point of REST is that API consumers can use the GraphQL query to get exactly what they need in a single request to avoid over or under fetching data. For example, let’s consider the API provider as a fridge, and the API consumer as a person who needs to get things out of the fridge.
Assume the person wants to get one fruit and one cold drink out of the fridge. Under the REST way, the person must get all the fruit out of the fridge, close the door, open again, and then get all the cold drinks, even the person only needs one of each. Under the GraphQL way, the person just need to open the fridge once, get the exact fruit and drink. That’s it. And GraphQL API also provides a number of other advantages, e.g. introducing schema to enable rapid frontend development. The GraphQL is the better REST article sheds some good lights on the details.
The GraphQL seems to have made the API consumers’ life a lot easier. But there is a price to pay from the API provider side. The provider side needs to handle the complexity due to various types of queries constructed from the consumer side. It makes the performance optimization harder for the provider end as well. So GraphQL probably is more suitable for big API providers but not so much for small ones. Hence, GraphQL is unlikely to fully replace REST.
Future of API
Predicting the future is hard. But my humble opinion is that none of the API types will disappear anytime soon. It’s like the grass weeds in the backyard. The stronger breeds will cover bigger areas but they will coexist with the others. And surely new weeds will join as well.
Talking about “new weeds”, different wind directions may bring new weeds to the backyard. There are two “wind directions” that are worth of mentioning: Low code development and event-driven architecture.
Low Code Development
One of the barriers that blocks more people from joining the API design and implementation is the coding. What if this barrier is removed? Like what we talked in the Components of API section earlier, when the smart phones and mobile apps started to get more end users involved, it significantly boosted the development of API. Similarly, if we can just use UIs to design and deploy APIs without worrying about coding, it will open the API world to way more people. These people usually are the ones who don’t know coding but have strong business process and business requirements in mind. It may bring API into another round of evolvement.
Event-Driven Architecture
The event-driven architecture (EDA) is another industry trend. The API communications we referred in our earlier sections are following the synchronous request-response pattern. In other words, the API consumers ask for something from the providers side and wait for the response. The API providers will then provide outputs back to the consumers accordingly. The EDA, on the contrary, is following the asynchronous subscription pattern. The providers need to provide a mechanism for consumers to subscribe, and the consumers need to provide API endpoints for the providers to post update events. This upside-down pattern may also be a game changer for the future of API. We’ll talk more about the EDA in another article.
In the end, the existing and new APIs will always have their pros and cons. Based on the requirements and environments, the API providers and consumers can choose the most suitable APIs from this big and evolving API family.
