In API7 Cloud, the Application is a high-level abstraction for a backend (or upstream) from API Gateway's point of view. In terms of architecture, it's equivalent to a micro-service, which contains a set of APIs (all of them will be effective on the API Gateway).
How to create an Application
After you sign in to API7 Cloud and click on the Applications tab (under the API Management), API7 Cloud will redirect you to the Application list page (this is the place where you can find all existing Applications).
Press the Create Application button and fill out the form to create the Application.
Three kinds of content that you should fill in to create an Application:
Basic, where you can specify the Application name, description, protocol, and other fields.
Upstream, where you can specify the upstream address (URL).
Policies, where you can specify a set of policies.
Get Application Details
On the Application List page, search for the Application you want, and click on the Application name. API7 Cloud will redirect you to the Application details page.
On the detail page, you can see the following attributes of this Application:
- Basic information (e.g., Protocol, Host)
- Upstream information
- API list
- Policies on this Application
- Canary Release rules
Delete an Application
IT'S DANGEROUS TO DELETE AN APPLICATION UNLESS YOU KNOW IT'S NO LONGER USED.
Delete all the APIs in the Application before you try to delete the Application, or the delete operation will fail.
Click on the trash icon to delete the Application, and you need to fill in the name of the target Application.
Some fields are vital for the API to work.
Which protocol the Application will use. Currently, candidates are
HTTP. The Application only handles HTTP traffic.
HTTPS. The Application only handles HTTPS traffic. In such a case, data plane instances will redirect requests sent to the HTTP port to the HTTPS port.
HTTP, HTTPS. The Application handles both HTTP and HTTPS traffic.
Path Prefix is the path prefix of the Application. It'll be used with the API Path
together to form the full API path.
Host indicates the HTTP Host header value for requests to the Application.
Fields in the Upstream section specify details about the upstream (in other words, the backend micro-service).
API7 Cloud supports configuring multiple Upstream versions for the same Application. This feature is always used with the Canary Release so that your backend service can transit from the old version to the new one smoothly.
You can only create one Upstream version (version name will be
default) when creating the Application.
By default, you just need to specify the upstream address (URL), e.g.,
Upstream Version in Use
This field indicates which Upstream version is used. All API requests will be forwarded to this Upstream version (if no Canary Release rule is active).
Upstream Advanced Settings
If the use case is simple, you just need to fill in the backend service address. However, some advanced settings might be helpful when the scenarios are complicated.
All the advanced upstream settings are collapsed by default. Click on View Advanced Upstream Options to unfold them.
If the backend service asks the client to provide the certificate as the identifier, you need to enable the Mutual TLS feature for this upstream version. Please refer to Enable Upstream Mutual TLS for more details.
Load balancing is trivial if you just have one endpoint for the backend service, but it's crucial when you have multiple. You can select the desired load balancing algorithm and input several endpoints and weights.
Available load balancing algorithms are:
- Round Robin: API7 Cloud uses the weighted one.
- Least Connection: Schedule according to the existing connections of each endpoint.
- Exponentially Weighted Moving Average (EWMA)
You can also customize the timeout settings for this upstream version if the default ones are not
appropriate for you. The connect timeout, read timeout, and send timeout are
The timeouts are set for only between two successive write/read operations, not for the transmission of the whole response.
Retry field controls the retry times for requests to this upstream version. By default,
it's equal to the number of endpoints minus
1 for this upstream version, e.g., if you configure five endpoints, then
requests will retry at most four times. It doesn't contain the time that the initial request to the backend. Set it to
0 will disable
When will Apache APISIX trigger retry?
- An error occurred while establishing a connection with the endpoint, passing a request to it, or reading the response header;
- A timeout has occurred while establishing a connection with the endpoint, passing a request to it, or reading the response header;