Concept Review: APIs and API Interconnections

Original author: NGINX

Original link:Concept review: API and API interconnection

Reprint source: NGINX open source community


NGINX’s only official Chinese community, all atnginx.org.cn

With the rise of microservice architecture, the number of APIs has increased dramatically, which has also produced a series of challenges and solutions. Read this article to learn about basic concepts related to APIs and the current state of API usage.

What is an application programming interface (API)?

An application programming interface (API) is a set of definitions, rules, and protocols that support communication between two entities: users (people or software) and information (data resources provided by online and web applications).

Today, APIs form the basic framework of modern applications, helping improve user experience and enhance business models. Sometimes, APIs can even serve as a business model in their own right.

How does the API work?

An API is the "face" of an application, showing what functions the application performs and the information it can provide, and defines the correct request format. When a developer creates an API for an app and exposes it, it allows other apps to communicate with that app.

In many cases, APIs help developers save valuable time because they make commonly used functionality readily available. Developers can integrate the required functionality into their own applications by calling APIs from existing applications without having to waste time re-developing those features.

The way each API is designed, deployed, and operated depends on its architectural style or protocol.

API architecture and protocol types 

API architecture or architectural style refers to the top-level design of an API, including how the API is structured and organized and its request/response format. The API protocol not only specifies the format, but also describes the exact message.

Common API architectures and protocols include:

  • REST — Also known as RESTful, this architectural style is based on the principles of characterizing state transfers. It uses HTTP methods (such as GET, POST, PUT, and DELETE) and abstract information (in the form of resources and resource models) to create an extensible, flexible, and technology-independent structure. Today, REST remains the most popular API architecture.

  • GraphQL — An open source query language developed by Meta (formerly Facebook), the GraphQL architecture supports fetching data from multiple sources with a single API call. Because clients only request necessary data, GraphQL APIs tend to be more efficient (but less cacheable) than REST APIs.

  • SOAP —— This architectural approach usesSimple Object Access Protocol (SOAP). SOAP messages are typically in XML format, making them slightly more clunky than REST or GraphQL. Unlike REST APIs, SOAP APIs use strict implementation guidelines to define the structure of the API protocol.

  • WebSocket - This API protocol is a full-duplex communication protocol, meaning that the client and server can send and receive messages at the same time. Furthermore, messages sent by the server may not be in response to client requests, but (for example) triggered by events on the server side. In contrast, REST APIs follow a strict request-response pattern.

  • RPC - With Remote Procedure Call, developers can use the same code to call Functions running in a different address space (usually on the remote server) - just like calling a local function without having to specify the details of the remote interaction. This protocol is flexible because it can be used in many languages, and is often used for client-server communication. gRPC (Google Remote Procedure Call) is a type of RPC.

API usage status 

APIs are a key component of modern software, and businesses today build or use many different types of APIs depending on their needs.

The four most common APIs in enterprises today arepublic APIs, private APIs, partner APIs, and third-party APIs.

Public API 

Public APIs are accessible to users outside your enterprise (either paid or free), allowing you to partner with third-party developers and expand your entire business ecosystem.

Because public APIs can be used by third-party developers to build new products, they help drive innovation and are an important tool to help forge new partnerships.

Private API 

Accessible only to teams within your enterprise, private APIs not only help you unlock data and facilitate internal collaboration, but also provide invisible support for your enterprise's public-facing applications, such as your website.

Because private APIs are only available to internal users, enterprises can build with optimization in mind. Private APIs also increase the composability of modern applications, allowing enterprises to adapt to their current needs. Developers can easily integrate private APIs when building microservices, reducing duplication of effort between teams.

Partner API

The Partner API is used to directly integrate business partner solutions (for example, when an airline partners with a hotel chain, you can book flights and hotels together). The Partner API is not publicly available — it is only accessible to a select group of developers who meet the authentication (AuthN) and authorization (AuthZ) requirements of both companies.

Interoperability strengthens relationships with partner APIs because they break down silos and enable different businesses to communicate with each other.

Third-party API 

Third-party APIs can be used by enterprises to access data or functionality that is missing from apps and services. These APIs run on third-party servers and often provide widely needed services (such as the Stripe payment processing API used by many e-commerce sites). These APIs can be used by businesses for a fee or for free, depending on the API.

Since third-party APIs are built by other developers or businesses, there are significant cost savings. Additionally, third-party APIs are an important way for enterprises to accelerate application development because developers can immediately use the functionality they need without having to write it themselves.

Which application languages ​​are used to create APIs?

Almost any modern programming language can be used to code APIs. When coding an API, many developers may choose to use a framework. Frameworks provide building blocks such as code libraries and other necessary utilities to make building applications using the language faster and easier.

Each programming language generally has one or more frameworks that are commonly used by developers. The table below lists several framework options (many of which are open source).

The exact choice of language and framework often depends on project needs or the developer's personal preferences.

API example

APIs are a fundamental part of modern software development, and there are countless examples of them. Here, we only give a few examples.

Three API examples:

  • Google Maps Platform — An API provided by Google that allows you to embed Google Maps into a website or app.

  • AWS IoT — The AWS IoT API enables you to connect devices on the Internet of Things, such as smart home devices, to the AWS Cloud. This is one way to build a smart home automation system.

  • NGINX Unit Control API - The Unit API uses a REST architecture to configure open source NGINX Unit applications and web servers.

What is an API policy?​ 

Enterprises need to develop a modern API strategy based on their business goals, which sets out how enterprises design, develop, manage, govern and secure their APIs.

According to Gartner's "Five API Lessons for Software Engineering Leaders," five best practices exist to help you ensure you implement a strong API strategy:

  • Don’t let API governance create a bottleneck. There needs to be a balance between API governance and developer agility to continuously drive innovation.

  • Think of APIs as products, even if you don't plan to make money from them. Ensure each API has a clear purpose and audience that matches business goals.

  • Discover your API before hackers do. A focus on discoverability and regular monitoring can help prevent security breaches.

  • Manage the life cycle of the API. Comprehensive API lifecycle management ensures that APIs continue to operate with appropriate security protections.

  • Choose the most appropriate API technology. What works for other businesses may not work for you, so you must consider your specific current and future API needs in detail.

No matter what type of API architecture you choose or what type of API you're writing, API security must be considered from the beginning, not made up after the fact.

What is API interconnection?​ 

"API interconnection" refers to the use of modular and reusable APIs to connect data and applications in a cloud native environment. Unlike API management, which focuses on managing the lifecycle of individual APIs, API interconnection involves loosely coupled microservice environments (where many APIs communicate with each other) and enables the protection and governance of APIs at scale in these architectures.

While APIs were once viewed simply as tools for developers, they have now become strategic business assets that not only help generate revenue but also support enterprise agility. As enterprises continue to innovate and adopt APIs, this creates new challenges for visibility, security, and governance. Enterprises need new API interconnection solutions that complement traditional and microservices architectures, align with DevOps practices, and support high-performance APIs.

API Types and API Interconnect Experience 

In the past, full lifecycle API management solutions were mainly used to manage north-south traffic (client to backend) of internal or external APIs. Now, as cloud-native infrastructure continues to generate more east-west traffic (between microservices within enterprise application infrastructure), the types of APIs have increased.

Currently, most enterprises use four types of APIs:

  • Internal API — Exposed only to other applications within the enterprise (and their developers), not to external users. Internal APIs help unlock data and facilitate collaboration across functions within the enterprise.

  • External API — Exposed to users outside the enterprise. External APIs enable partnerships with third-party developers and your entire business ecosystem and can be a source of revenue.

  • Partner API — Exposed to business partners. These APIs are not public — they are only accessible to a select group of developers who meet the authentication (AuthN) and authorization (AuthZ) requirements of both enterprises.

  • Third Party API — Exposed by a third party and hosted on their servers. These APIs are often used to provide widely needed services (such as maps) and are developed specifically for use by other companies, typically for a fee.

Other key elements of API interconnection include API gateways (reverse proxies or ingress controllers) and API developer portals. The API gateway accepts API requests from clients, directs them to the corresponding service, and integrates the request results into the user's synchronous experience. The Developer Portal is an online platform where you can publish resources to help API consumers get started quickly, such as a catalog of external APIs, comprehensive documentation, and sample code. It also allows third-party developers to register their apps and obtain API access credentials.

Multi-cloud challenges

Today, both APIs and microservices will be deployed in multiple environments—public cloud, private cloud, on-premises, and at the edge. Asmicroservices increasingly become a key tool for high-traffic companies to scale applications, internal API traffic has also increased significantly. 

The proliferation of API endpoints in complex multi-cloud environments requires a new approach to API management, governance and security. These distributed environments require low-touch, automated approaches to empower developers and enable platform operations teams to set up security and resource protection across different lines of business.

Ensuring the reliability and security of multi-cloud architectures poses serious challenges to platform operation and maintenance teams. They need complete visibility into application and API traffic and the ability to apply consistent security and compliance policies across different environments. Platform-native tools operate differently and provide varying degrees of visibility and control. Ultimately, platform operations teams will need to use other models to create and apply governance rules across distributed teams and environments.

There are two common models for API governance — centralized and decentralized. But in modern API strategies, especially in API-first models, the new concept of “adaptive governance” empowers API developers while providing reliability and security control to platform operations teams.

For more information, read our blog post Adaptive governance gives API developers the autonomy they need.

The Importance of API-First Tools

Cloud-native environments are loosely coupled systems typically built using containers, service meshes, and microservices. The above resources communicate with each other through APIs and are often managed autonomously through declarative APIs. These techniques enable building systems that are fault tolerant, easy to manage, and easy to observe.

API Interconnect emphasizes the use of cloud-native technologies, specifically an API-first approach to managing infrastructure and API lifecycles. This is especially important when automating operations at scale using continuous integration/continuous delivery (CI/CD) practices. CI/CD helps you efficiently manage APIs and applications throughout their entire lifecycle (authoring, delivery, and updates) through automation capabilities. It also enables security policies to be integrated and embedded early and then applied to future APIs, helping to “shift security left” and integrating security protections throughout the development process, all the way to production.

What is the difference between API interconnection and API-led interconnection strategies?

"API-led interconnection" is a specific architectural approach to digital transformation and an enterprise's overall API strategy. It uses a layered approach to classify enterprise APIs by function:

  • System API is used to obtain raw data from the system of record and expose it to the upstream API in a reliable way

  • Process API Orchestrates multiple downstream system APIs to aggregate data and apply business logic to the data

  • Experience API enables user-facing interactions and can be reused in mobile and web applications

No matter which architectural pattern you use to classify your APIs, API interconnection is a comprehensive approach to governing and operating APIs in a cloud-native environment.


NGINX is the only official Chinese community, all at nginx.org.cn

More technical information, interactive Q&A, series of courses, and event resources related to NGINX: Open source community official website | WeChat public account

IntelliJ IDEA 2023.3 & JetBrains annual major version update New concept "defensive programming": make yourself a stable job GitHub .com runs more than 1,200 MySQL hosts, how to seamlessly upgrade to 8.0? Stephen Chow’s Web3 team will launch an independent app next month Will Firefox be eliminated? Visual Studio Code 1.85 released, floating window US CISA recommends abandoning C/C++ to eliminate memory security vulnerabilities Yu Chengdong: Huawei Disruptive products will be launched next year and rewrite the history of the industry TIOBE December: C# is expected to become the programming language of the year Lei Jun’s paper written 30 years ago: "Computer Virus Determination Expert System Principles and Design
{{o.name}}
{{m.name}}

Guess you like

Origin my.oschina.net/u/5246775/blog/10143233