What is API?

The API is a combination of a set of definitions and protocols that can be used to build and integrate applications. API is the abbreviation of "application programming interface".

Through API, even if you don't know how to operate, you can also connect your products or services with others. This can simplify application development and save time and cost. When you develop new tools and products, or manage existing tools and products, powerful and flexible APIs can help you simplify design, management and use, and bring more innovation opportunities.

API is sometimes regarded as a contract, and the contract text represents the agreement between the parties: if one party sends a remote request in a specific way, the agreement specifies how the other party's software will respond. Because APIs simplify the way developers integrate new application components into their existing infrastructure, they also help collaboration between the business and it teams.

With the rapid development of the digital market, the business demand usually changes rapidly. New competitors can change the whole industry with new applications. In order to maintain competitiveness, it is particularly important to support rapid development and deployment of innovative services. Cloud native application development is a clear way to improve the development speed, relying on the connection of microservice application architecture through API.

API is a simplified way to connect your own infrastructure through cloud native application development, and also enables you to share your data with customers and other external users. The public API has unique business value because it can simplify and expand your contact with partners, and it is expected to support you to make profits from data (Google Maps API is one of the well-known cases).

For example, let's suppose there is a book distribution company: the publisher can provide an application for the bookstore clerk to check the book inventory. The development cost of this application is high, there are platform restrictions, the development cycle is long, and it needs daily maintenance. Alternatively, the publisher can provide an API to query the inventory status. This approach has several advantages: the API can help them gather all inventory related information in one place, so that customers can easily access the data. As long as the behavior of the API does not change, the book publisher can change the internal system without affecting customers. With publicly available APIs, developers can develop an application for the book publisher, book seller or third party to help customers find the books they need. This will not only increase sales, but also bring other business opportunities.

In short, the API allows you to open your access to resources, ensure security, and keep you in control. How and to whom access is open is up to you. Good API management is the key to API security. With a distributed integration platform that connects various resources, including traditional systems and the Internet of things, you can connect to the API and create applications that use the data or functions provided by the API.

There are three options for API publishing strategies.

Private: this kind of API is only for internal use, and allows companies to control their own API to the maximum extent.

Partners: you will share these APIs with specific business partners. It can bring additional benefits without affecting quality.

Public: this kind of API can be used by everyone. Third parties can use these APIs to develop applications that interact with your API or implement some innovation.

Innovation with APIs by providing your API to partners or the public, you can: create new revenue channels, or expand existing revenue channels. Expand your brand coverage. Promote open innovation or efficiency through external development and collaboration.

That sounds good, doesn't it? However, how does API achieve the above points? Let's continue to take the book distribution company as an example. Suppose one of the company's partners developed an application that could help people find books on bookshelves. The improvement of this experience has brought more customers (customers of the publisher) to the bookstore and expanded the existing revenue channels.

Perhaps a third party will use a public API to develop applications so that people can buy books directly from the publisher, not the bookstore. This will open up new revenue channels for the book publishers.

Sharing APIs with specific partners or around the world can have a positive impact. In addition to your own company's marketing activities, every partnership can help you improve your brand identity. Opening technology to everyone in the form of a public API can motivate developers to build an application ecosystem centered around your API. More people use your technology, which means more people may do business with you.

Open technology can bring unexpected joy. Sometimes, these surprises can turn the industry upside down. For this book distribution company, the new form of company (such as book lending service) may completely change their business model. With partners and public APIs, you can inspire community members (far more than your internal development team). All kinds of wonderful ideas will emerge continuously. The company only needs to identify the changes in the market and make corresponding preparations. API is very useful.

Brief history of API

The concept of API began at the beginning of the computer age, far before the birth of personal computers. At that time, Apis were often used as libraries for operating systems, and they were basically run on local systems, only occasionally used to deliver messages between mainframes. Nearly 30 years later, APIs are out of their local environment. By the beginning of the 21st century, API has become an important technology for data remote integration.

Remote API

The remote API is designed to interact over a communication network. "Remote" here means that the resource controlled by API is not on the requesting computer. Because the Internet is the most widely used communication network, most APIs are designed based on Web standards. Not all remote APIs are web APIs, but you can think of Web APIs as remote APIs.

The web API usually uses HTTP to transmit request messages and provides the structure definition of response messages. These response messages are usually provided in the form of XML or JSON files. XML and JSON are both preferred formats because they render data in a way that is easy for other applications to manipulate.

What are the API improvements?

In the process of API developing into web API, people have improved it, simplified the design and improved its implementation effect.

Less soap, more rest

With the continuous popularization of Web API, the corresponding protocol specifications have been produced, which promotes the standardization of information exchange: Simple Object Access Protocol, or soap for short. The API designed with soap uses XML format to send and receive messages, and uses HTTP or SMTP to receive requests. When using soap, applications running in different environments or written in different languages can share information more easily.

There is another related specification: representational state transfer (rest). Web APIs that follow the constraints of rest architecture are called restful APIs. There is a fundamental difference between rest and soap: soap is a protocol, while rest is an architectural pattern. This means that there is no official standard for restful web APIs. As defined by Roy fielding in the paper "architectural styles and the design of network-based software architecture", as long as the API conforms to the six guiding constraints of restful system, it is regarded as restful API:

Client / Server Architecture: rest architecture is composed of client, server and resource, which processes requests through HTTP.

Stateless: no client content is stored on the server through which the request passes. Information about the session state is stored on the client. Cacheability: through caching, some interaction between client and server can be avoided.

Layered system: the interaction between client and server can be mediated through additional layers. These layers can provide additional functionality, such as load balancing, shared caching, or security.

On demand code (optional): the server can extend the function of the client by transferring executable code.

Unified interface: this constraint is the design core of restful API, covering four levels:

Identify the resource in the request: the resource in the request is identified and separated from the representation returned to the client.

Manipulate resources through different representations: clients receive files representing different resources. These representations must provide sufficient information for modification or deletion.

Self describing message: each message returned to the client contains sufficient information to indicate how the client should process the received information.

Using hypermedia as the engine of application state: after accessing a resource, the rest client should be able to discover all other operations currently available through hyperlinks.

Although it seems that there are many constraints to follow, they are much easier to follow than to follow the prescribed protocol. As a result, the restful API is now becoming more popular than soap.

In recent years, OpenAPI specification has become a general standard to define rest API. OpenAPI provides a language independent way for developers to build rest API interfaces, so as to minimize uncertainties and make users feel at ease.

SOA and microservice architecture

The two most commonly used architectures for remote APIs are service-oriented architecture (SOA) and microservice architecture. Among these two solutions, SOA has a long history. At first, it was developed on the basis of monomer application. Although a single single single application can also complete various operations, some functions can be obtained after loose coupling between different applications through some integration mode (such as enterprise service bus (ESB)).

At most levels, SOA is simpler than a monolithic architecture; however, without a clear understanding of component interactions, SOA can further complicate the entire environment. This increase in complexity will re ignite some of the problems that SOA wants to solve.

For the use of specialized loosely coupled services, the microservice architecture is similar to the SOA pattern. However, the microservice architecture will further subdivide the traditional architecture. In the microservice architecture, services will adopt a common messaging framework, such as the restful API. They use restful APIs to communicate with each other, and do not need to perform tedious data conversion processing or use other integration layers. Using restful APIs can speed up the delivery of new functions and updates; it can even be said that such APIs promote this speed. Each service in the architecture is in a discrete state. A service can be replaced, enhanced, or discarded without affecting any other service in the architecture. This lightweight architecture helps optimize distributed or cloud resources and supports the dynamic expansion of individual services.