Key Concepts

Cluster

In API7 Enterprise, the concept of a cluster refers to the API7 Gateway cluster. Each cluster is composed of multiple nodes that work together, including multiple data plane nodes and one control plane node. These nodes can communicate with each other and coordinate their work to provide a highly available, high-performance, and scalable API gateway service. When a user sends an API request to the API7 Gateway cluster, the request is routed to an available data plane node for processing. If a data plane node fails or becomes unavailable, other data plane nodes continue to process the request, ensuring the stability and reliability of the system. All data plane nodes in the same cluster read the same gateway configuration stored in etcd resource and execute exactly the same business logic. The configuration between different clusters is isolated, and modifications made to the current cluster do not affect other clusters. If a current cluster fails, it will not affect other clusters. Each cluster has a different external address, and the API caller needs to specify which API7 Gateway cluster the request should be sent to and use the corresponding address.

Workspace

A workspace refers to a segregated area or partition within an API7 Gateway cluster, where upstreams, routes/APIs, consumers, certificates, plugin templates, global plugins, and other resources are grouped and managed independently by different teams. By utilizing multiple workspaces, API7 Enterprise enables multi-tenant management.

Workspaces are only intended for visibility and editing permissions of resources and do not affect the reception, processing, and forwarding of APIs. API consumers do not need to be aware of the specific workspace configuration.

All workspaces within the same cluster still share data plane and control plane nodes. Therefore, if a node malfunctions, all workspaces will be affected.

etcd Resource

etcd is a component used by the API7 Gateway to store configuration data. An etcd resource refers to an etcd cluster. For high availability, it is recommended to have at least three nodes in an etcd cluster. Configuration data for different gateway clusters can be stored in different etcd clusters, which enhances security through resource isolation, or in the same etcd cluster for centralized management and resource efficiency.

Upstream

The upstream concept in API7 is consistent with the upstream concept in Apache APISIX. Learn about upstream.

Route/API

The concept of route/API in API7 is consistent with the concept of route in Apache APISIX.

Learn about route.

Plugin Template

The concept of plugin template in API7 is consistent with that in Apache APISIX.

Learn about plugin template.

caution

• Plugins in API7 cannot be configured directly on routes/APIs and must be used through plugin templates.
• Consumers can directly use one or more plugins without going through a plugin template.

Consumer

The concept of consumer in API7 is consistent with that in Apache APISIX. Learn about consumer.

Data Plane Node

Also known as gateway nodes, data plane nodes refer to nodes in the API7 gateway cluster where API7-Gateway services are deployed. Data plane nodes are one of the core components of API7, responsible for actually processing all incoming API requests and returning responses.

For production, it is recommended to deploy two or more data plane nodes to prevent single point of failure.

Control Plane Node

Control plane node, also known as API7-Dashboard node, refers to a node where the API7-Dashboard service is deployed in the gateway cluster. It is responsible for receiving configuration modification requests for the API7 gateway, managing the online and offline status of API7 gateway nodes, and controlling the forwarding rules of traffic.

For production, data plane nodes and control plane nodes are deployed separately, and each gateway cluster requires at least one control plane node.

Developer Portal

API7 Developer Portal is a sub-functionality of the API7 Enterprise. It allows API providers to publish APIs configured on API7 Enterprise to the Developer Portal, making it convenient for API consumers to subscribe and use them. With the authentication, rate limiting, and other capabilities provided by API7 Enterprise, APIs can be well-protected to ensure their security.

Developer portals are typically divided into two sites: an admin site(for API providers) and a display site(for API consumers).

The core functions of the management site include:

• Control the release and removal of APIs on the display site. Only APIs that have been released are visible on the display site.
• Add policies to the published APIs, such as rate limiting, authentication, etc.
• Approve requests from the display site, including developer account registration and application subscription to a specific API.

The core functions of the display site include:

• Allow API consumers to view all APIs that have been published by API providers, including OpenAPI documentation and detailed information.
• Allow API consumers to subscribe for API on behalf of their applications.
• Create credential for accessing subscribed APIs.

Organization

An organization is responsible for managing developers and applications, and data between organizations is isolated, which can be used for multi-tenant management.

info

Currently, only the default organization is provided, and support for creating and managing custom organizations will be added in the future.

Application

The subject who subscribes to the API and initiates the call, created by the API consumers, usually corresponds to a product or a group of services.

• Each application will have a set of API keys as credentials for calling the API.
• Applications belong to an organization rather than a specific API consumer. Authorized developers within the organization can view the application information and use the API keys. In the perspective of API producers, they are the same call source.
• Each application corresponds to a consumer in the gateway.

API

Corresponds to a route/API on the gateway.

• Modifying the properties or deleting a route/API on the gateway will also result in changes to the corresponding API on the developer portal.
• If a route/API on the gateway is not intended to be exposed to the public, it does not need to be published to the developer portal.

API Subscription

API consumers apply for API subscription with the application as the subject. That is, the permission and credentials for calling the API do not belong to a specific person, but should belong to an application.

After a successful subscription, the application can call this API. If the API is authenticated, the application will obtain the corresponding access credentials.

• For the same API, the access credentials of different applications are different, but for the same application, if multiple APIs using the same authentication method are subscribed, the corresponding access credentials are the same.
• If the subscription of a certain application for the current API is cancelled, the access credentials of this application will be invalidated.
• Each API subscription is mapped to adding the corresponding consumer to the access whitelist in the associated route of the API; cancelling the API subscription is mapped to removing the corresponding consumer from the access whitelist in the associated route of the API. Therefore, if the access whitelist in the associated route of the API is directly changed on the API7 Gateway side, it will break the API subscription relationship and cause errors.

info

If the API does not enable any authentication, in fact, any application can access it directly without subscription. Currently, changing the access credentials of a successfully subscribed application is not supported.