This is an automated email from the ASF dual-hosted git repository.
monkeydluffy pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/apisix.git
The following commit(s) were added to refs/heads/master by this push:
new 9d34d28fa docs: improve upgrade guide (#10551)
9d34d28fa is described below
commit 9d34d28fa7c1ab70e1acb61196fb91ad46c167cb
Author: Navendu Pottekkat <[email protected]>
AuthorDate: Tue Nov 28 07:43:12 2023 +0530
docs: improve upgrade guide (#10551)
---
.../latest/upgrade-guide-from-2.15.x-to-3.0.0.md | 748 ++++++++++-----------
1 file changed, 347 insertions(+), 401 deletions(-)
diff --git a/docs/en/latest/upgrade-guide-from-2.15.x-to-3.0.0.md
b/docs/en/latest/upgrade-guide-from-2.15.x-to-3.0.0.md
index 36d364e8b..de51e45ab 100644
--- a/docs/en/latest/upgrade-guide-from-2.15.x-to-3.0.0.md
+++ b/docs/en/latest/upgrade-guide-from-2.15.x-to-3.0.0.md
@@ -4,7 +4,7 @@ keywords:
- APISIX
- APISIX Upgrade Guide
- APISIX Version Upgrade
-description: This document will guide on you how to upgrade your APISIX
version.
+description: Guide for upgrading APISIX from version 2.15.x to 3.0.0.
---
<!--
@@ -26,483 +26,429 @@ description: This document will guide on you how to
upgrade your APISIX version.
#
-->
-## Upgrade path for APISIX
+This document guides you in upgrading APISIX from version 2.15.x to 3.0.0.
-APISIX adheres to [semantic versioning](https://semver.org/).
+:::note
-Upgrading to APISIX 3.0.0 is a major version upgrade and we recommend that you
upgrade to 2.15.x first and then to 3.0.0.
+Upgrading to version 3.0.0 is a major change and it is recommended that you
first upgrade to version 2.15.x before you upgrade to 3.0.0.
-## From 2.15.x upgrade to 3.0.0
+:::
-### Upgrade Notes and Major Updates
+## Changelog
-Before upgrading, please check the
[3.0.0-beta](../../../CHANGELOG.md#300-beta) and
[3.0.0](../../../CHANGELOG.md#300) in the Change section for incompatible
changes and major updates for version 3.0.0.
+Please refer to the
[3.0.0-beta](https://github.com/apache/apisix/blob/master/CHANGELOG.md#300-beta)
and [3.0.0](https://github.com/apache/apisix/blob/master/CHANGELOG.md#300)
changelogs for a complete list of incompatible changes and major updates.
-#### Deploy
+## Deployments
-The alpine-based image is no longer supported, so if you are using the alpine
image, you will need to replace it with a debian/centos-based image.
+From 3.0.0, we no longer support the Alpine-based images of APISIX. You can
use the [Debian or CentOS-based
images](https://hub.docker.com/r/apache/apisix/tags?page=1&ordering=last_updated)
instead.
-Currently, we provide:
+In addition to the Docker images, we also provide:
-- debian/centos-based images, you can find them on
[DockerHub](https://hub.docker.com/r/apache/apisix/tags?page=1&ordering=last_updated)
-- RPM packages for CentOS 7 and CentOS 8, supporting amd64 and arm64
architectures, refer to [install via RPM
repository](./installation-guide.md#installation-via-rpm-repository)
-- DEB package for Debian 11 (bullseye), supporting amd64 and arm64
architectures, see [install via DEB
repository](./installation-guide.md#installation-via-deb-repository)
+1. RPM packages for CentOS 7 and CentOS 8 supporting both AMD64 and ARM64
architectures.
+2. DEB packages for Debian 11 (bullseye) supporting both AMD64 and ARM64
architectures.
-3.0.0 makes major updates to the deployment model, as follows:
+See the [installation guide](/installation-guide.md) for more details.
-- Support the deployment mode of separating data plane and control plane,
please refer to [Decoupled](./deployment-modes.md#decoupled)
-- If you need to continue using the original deployment mode, then you can use
the `traditional` mode in the deployment mode and update the configuration
file, please refer to [Traditional](./deployment-modes.md#traditional)
-- Support Standalone mode, need to update the configuration file, please refer
to [Standalone](./deployment-modes.md#standalone)
+3.0.0 also introduces multiple deployment modes. The following modes are
supported:
-#### Dependencies
+1. [Traditional](./deployment-modes.md#traditional): As the name implies, this
is the original deployment mode where one instance of APISIX acts as the
control plane and the data plane. Use this deployment mode to keep your
deployment similar to older versions.
+2. [Decoupled](./deployment-modes.md#decoupled): In this mode, the data plane
and the control plane are separated. You can deploy an instance of APISIX
either as a control plane or a data plane.
+3. [Standalone](./deployment-modes.md#standalone): Using this mode will
disable etcd as the configuration center and use a static configuration file
instead. You can use this to manage APISIX configuration decaratively or for
using other configuration centers.
-If you use the provided binary packages (Debian and RHEL), or images, then
they already bundle all the necessary dependencies for APISIX and you can skip
this section.
+## Dependencies
-Some features of APISIX require additional NGINX modules to be introduced in
OpenResty. To use these features, you need to build a custom OpenResty
distribution (APISIX-Base). You can build your own APISIX-Base environment by
referring to the code in
[api7/apisix-build-tools](https://github.com/api7/apisix-build-tools).
+All Docker images and binary packages (RPM, DEB) already come with all the
necessary dependencies for APISIX.
-If you want APISIX to run on native OpenResty, then only OpenResty 1.19.3.2
and above are supported.
+Some features might require additional Nginx modules in OpenResty and requires
you to [build a custom OpenResty distribution
(APISIX-Base)](https://github.com/api7/apisix-build-tools).
-#### Migrations
+To run APISIX on a native OpenResty instance use [OpenResty version
1.19.3.2](https://openresty.org/en/download.html#legacy-releases) and above.
-##### Static configuration migration
+## Configurations
-APISIX is configured to override the default `conf/config-default.yaml` with
the contents of custom `conf/config.yaml`, or if a configuration does not exist
in `conf/config.yaml`, then use the configuration in
`conf/config-default.yaml`. In 3.0.0, we adjusted `conf/config-default.yaml`.
+There are some major changes to the configuration file in APISIX. You need to
update your configuration file (`conf/config.yaml`) to reflect these changes.
See the `conf/config-default.yaml` file for the complete changes.
-###### Move configuration
+The following attributes in the configuration have been moved:
-From version 2.15.x to 3.0.0, the location of some configuration in
`conf/config-default.yaml` has been moved. If you are using these
configuration, then you need to move them to the new location.
+1. `config_center` is replaced by `config_provider` and moved under
`deployment`.
+2. `etcd` is moved under `deployment`.
+3. The following Admin API configuration attributes are moved to the `admin`
attribute under `deployment`:
+ 1. `admin_key`
+ 2. `enable_admin_cors`
+ 3. `allow_admin`
+ 4. `admin_listen`
+ 5. `https_admin`
+ 6. `admin_api_mtls`
+ 7. `admin_api_version`
-Adjustment content:
+The following attributes in the configuration have been replaced:
- * `config_center` is now implemented by `config_provider` under `deployment`
- * The `etcd` field is moved to `deployment`.
- * The following Admin API configuration is moved to the `admin` field under
`deployment`
- - admin_key
- - enable_admin_cors
- - allow_admin
- - admin_listen
- - https_admin
- - admin_api_mtls
- - admin_api_version
+1. `enable_http2` and `listen_port` under `apisix.ssl` are replaced by
`apisix.ssl.listen`. i.e., the below configuration:
-You can find the exact new location of these configuration in
`conf/config-default.yaml`.
+ ```yaml title="conf/config.yaml"
+ ssl:
+ enable_http2: true
+ listen_port: 9443
+ ```
-###### Update configuration
+ changes to:
-Some configuration have been removed in 3.0.0 and replaced with new
configuration. If you are using these configuration, then you need to update
them to the new configuration.
+ ```yaml title="conf/config.yaml"
+ ssl:
+ listen:
+ - port: 9443
+ enable_http2: true
+ ```
-Adjustment content:
+2. `nginx_config.http.lua_shared_dicts` is replaced by
`nginx_config.http.custom_lua_shared_dict`. i.e., the below configuration:
- * Removed `enable_http2` and `listen_port` from `apisix.ssl` and replaced
with `apisix.ssl.listen`
+ ```yaml title="conf/config.yaml"
+ nginx_config:
+ http:
+ lua_shared_dicts:
+ my_dict: 1m
+ ```
- If you have this configuration in `conf/config.yaml` like:
+ changes to:
- ```yaml
- ssl:
- enable_http2: true
- listen_port: 9443
- ```
+ ```yaml title="conf/config.yaml"
+ nginx_config:
+ http:
+ custom_lua_shared_dict:
+ my_dict: 1m
+ ```
- Then you need to change it to:
+ This attribute declares custom shared memory blocks.
- ```yaml
- ssl:
- listen:
- - port: 9443
- enable_http2: true
- ```
+3. `etcd.health_check_retry` is replaced by `deployment.etcd.startup_retry`.
So this configuration:
- * Removed `nginx_config.http.lua_shared_dicts` and replaced with
`nginx_config.http.custom_lua_shared_dict`, this configuration is used to
declare custom shared memory blocks. If you have this configuration in
`conf/config.yaml` like:
+ ```yaml title="conf/config.yaml"
+ etcd:
+ health_check_retry: 2
+ ```
- ```yaml
- nginx_config:
- http:
- lua_shared_dicts:
- my_dict: 1m
- ```
+ changes to:
- Then you need to change it to:
+ ```yaml title="conf/config.yaml"
+ deployment:
+ etcd:
+ startup_retry: 2
+ ```
- ```yaml
- nginx_config:
- http:
- custom_lua_shared_dict:
- my_dict: 1m
- ```
+ This attribute is to configure the number of retries when APISIX tries to
connect to etcd.
- * Removed `etcd.health_check_retry` and replaced with
`deployment.etcd.startup_retry`, this configuration is used to configure the
number of retries when APISIX starts to connect to etcd. If you have this
configuration in `conf/config.yaml` like:
+4. `apisix.port_admin` is replaced by `deployment.admin.admin_listen`. So your
previous configuration:
- ```yaml
- etcd:
- health_check_retry: 2
- ```
+ ```yaml title="conf/config.yaml"
+ apisix:
+ port_admin: 9180
+ ```
- Then you need to change it to:
+ Should be changed to:
- ```yaml
- deployment:
- etcd:
- startup_retry: 2
- ```
+ ```yaml title="conf/config.yaml"
+ deployment:
+ apisix:
+ admin_listen:
+ ip: 127.0.0.1 # replace with the actual IP exposed
+ port: 9180
+ ```
- * Removed `apisix.port_admin` and replaced with
`deployment.admin.admin_listen`, this configuration is used to configure the
Admin API listening port. If you have this configuration in `conf/config.yaml`
like:
+ This attribute configures the Admin API listening port.
- ```yaml
- apisix:
- port_admin: 9180
- ```
+5. `apisix.real_ip_header` is replaced by `nginx_config.http.real_ip_header`.
- Then you need to change it to:
+6. `enable_cpu_affinity` is set to `false` by default instead of `true`. This
is because Nginx's `worker_cpu_affinity` does not count against the cgroup when
APISIX is deployed in containers. In such scenarios, it can affect APISIX's
behavior when multiple instances are bound to a single CPU.
- ```yaml
- deployment:
- apisix:
- admin_listen:
- ip: 127.0.0.1 # replace with the actual IP exposed
- port: 9180
- ```
+## Data Compatibility
- * Change the default value of `enable_cpu_affinity` to `false`. Reason: More
and more users are deploying APISIX via containers. Since Nginx's
worker_cpu_affinity does not count against the cgroup, enabling
worker_cpu_affinity by default can affect APISIX behavior, for example, if
multiple instances are bound to a single CPU. To avoid this problem, we disable
the `enable_cpu_affinity` option by default in `conf/config-default.yaml`.
- * Removed `apisix.real_ip_header` and replaced with
`nginx_config.http.real_ip_header`
+In 3.0.0, the data structures holding route, upstream, and plugin
configuration have been modified and is not fully compatible with 2.15.x. You
won't be able to connect an instance of APISIX 3.0.0 to an etcd cluster used by
APISIX 2.15.x.
-##### Data Migration
+To ensure compatibility, you can try one of the two ways mentioned below:
-If you need to backup and restore your data, you can use the backup and
restore function of ETCD, refer to [etcdctl
snapshot](https://etcd.io/docs/v3.5/op-guide/maintenance/#snapshot-backup).
+1. Backup the incompatible data (see [etcdctl
snapshot](https://etcd.io/docs/v3.5/op-guide/maintenance/#snapshot-backup)) in
etcd and clear it. Convert the backed up data to be compatible with 3.0.0 as
mentioned in the below examples and reconfigure it through the Admin API of
3.0.0 instance.
+2. Use custom scripts to convert the data structure in etcd to be compatible
with 3.0.0.
-#### Data Compatible
+The following changes have been made in version 3.0.0:
-In 3.0.0, we have adjusted some of the data structures that affect the
routing, upstream, and plugin data of APISIX. The data is not fully compatible
between version 3.0.0 and version 2.15.x. You cannot use APISIX version 3.0.0
to connect directly to the ETCD cluster used by APISIX version 2.15.x.
+1. `disable` attribute of a plugin has been moved under `_meta`. It enables or
disables the plugin. For example, this configuration to disable the
`limit-count` plugin:
-In order to keep the data compatible, there are two ways, for reference only.
-
- 1. Review the data in ETCD, back up the incompatible data and then clear it,
convert the backed up data structure to that of version 3.0.0, and restore the
data through the Admin API of version 3.0.0
- 2. Review the data in ETCD, write scripts to convert the data structure of
version 2.15.x into the data structure of version 3.0.0 in batch
-
-Adjustment content:
-
- * Moved `disable` of the plugin configuration under `_meta`
-
- `disable` indicates the enable/disable status of the plugin
-
- If such a data structure exists in ETCD
-
- ```json
- {
- "plugins":{
- "limit-count":{
- ... // plugin configuration
- "disable":true
- }
- }
- }
- ```
-
- In 3.0.0, the data structure of this plugin should be transformed to
-
- ```json
- {
- "plugins":{
- "limit-count":{
- ... // plugin configuration
- "_meta":{
- "disable":true
- }
- }
- }
- }
- ```
-
- Note: `disable` is the meta-configuration of the plugin, and this adjustment
takes effect for all plugin configurations, not just the `limit-count` plugin.
-
- * Removed `service_protocol` from the Route, and replaced it with
`upstream.scheme`
-
- If such a data structure exists in ETCD
-
- ```json
- {
- "uri":"/hello",
- "service_protocol":"grpc",
- "upstream":{
- "type":"roundrobin",
- "nodes":{
- "127.0.0.1:1980":1
- }
- }
- }
- ```
-
- In 3.0.0, the data structure of this plugin should be transformed to
-
- ```json
- {
- "uri":"/hello",
- "upstream":{
- "type":"roundrobin",
- "scheme":"grpc",
- "nodes":{
- "127.0.0.1:1980":1
- }
- }
- }
- ```
-
- * Removed `audience` field from authz-keycloak, and replaced it with
`client_id`
-
- If such a data structure of authz-keycloak plugin exists in ETCD
-
- ```json
- {
- "plugins":{
- "authz-keycloak":{
- ... // plugin configuration
- "audience":"Client ID"
- }
- }
- }
- ```
+ ```json
+ {
+ "plugins":{
+ "limit-count":{
+ ... // plugin configuration
+ "disable":true
+ }
+ }
+ }
+ ```
- In 3.0.0, the data structure of this plugin should be transformed to
+ should be changed to:
- ```json
- {
- "plugins":{
- "authz-keycloak":{
- ... // plugin configuration
- "client_id":"Client ID"
- }
- }
- }
- ```
-
-* Removed `upstream` field from mqtt-proxy, and configure `upstream` outside
the plugin and reference it in the plugin
-
- If such a data structure of mqtt-proxy plugin exists in ETCD
-
- ```json
- {
- "remote_addr":"127.0.0.1",
- "plugins":{
- "mqtt-proxy":{
- "protocol_name":"MQTT",
- "protocol_level":4,
- "upstream":{
- "ip":"127.0.0.1",
- "port":1980
- }
- }
- }
- }
- ```
-
- In 3.0.0, the data structure of this plugin should be transformed to
-
- ```json
- {
- "remote_addr":"127.0.0.1",
- "plugins":{
- "mqtt-proxy":{
- "protocol_name":"MQTT",
- "protocol_level":4
- }
- },
- "upstream":{
- "type":"chash",
- "key":"mqtt_client_id",
- "nodes":[
- {
- "host":"127.0.0.1",
- "port":1980,
- "weight":1
- }
- ]
- }
- }
- ```
-
- * Removed `max_retry_times` and `retry_interval` fields from syslog, and
replaced them with `max_retry_count` and `retry_delay`
+ ```json
+ {
+ "plugins":{
+ "limit-count":{
+ ... // plugin configuration
+ "_meta":{
+ "disable":true
+ }
+ }
+ }
+ }
+ ```
+
+2. `service_protocol` in route has been replaced with `upstream.scheme`. For
example, this configuration:
+
+ ```json
+ {
+ "uri": "/hello",
+ "service_protocol": "grpc",
+ "upstream": {
+ "type": "roundrobin",
+ "nodes": {
+ "127.0.0.1:1980": 1
+ }
+ }
+ }
+ ```
+
+ Should be changed to:
+
+ ```json
+ {
+ "uri": "/hello",
+ "upstream": {
+ "type": "roundrobin",
+ "scheme": "grpc",
+ "nodes": {
+ "127.0.0.1:1980": 1
+ }
+ }
+ }
+ ```
+
+3. `audience` field from the [authz-keycloak](./plugins/authz-keycloak.md)
plugin has been replaced with `client_id`. So this configuration:
+
+ ```json
+ {
+ "plugins":{
+ "authz-keycloak":{
+ ... // plugin configuration
+ "audience":"Client ID"
+ }
+ }
+ }
+ ```
- If such a data structure of syslog plugin exists in ETCD
+ should be changed to:
- ```json
- {
- "plugins":{
- "syslog":{
- "max_retry_times":1,
- "retry_interval":1,
- ... // other configuration
- }
- }
- }
- ```
-
- In 3.0.0, the data structure of this plugin should be transformed to
-
- ```json
- {
- "plugins":{
- "syslog":{
- "max_retry_count":1,
- "retry_delay":1,
- ... // other configuration
- }
- }
- }
- ```
-
- * The `scheme` field has been removed from proxy-rewrite, and the `scheme`
field has been added to upstream
+ ```json
+ {
+ "plugins":{
+ "authz-keycloak":{
+ ... // plugin configuration
+ "client_id":"Client ID"
+ }
+ }
+ }
+ ```
+
+4. `upstream` attribute from the [mqtt-proxy](./plugins/mqtt-proxy.md) plugin
has been moved outside the plugin conference and referenced in the plugin. The
configuration below:
+
+ ```json
+ {
+ "remote_addr": "127.0.0.1",
+ "plugins": {
+ "mqtt-proxy": {
+ "protocol_name": "MQTT",
+ "protocol_level": 4,
+ "upstream": {
+ "ip": "127.0.0.1",
+ "port": 1980
+ }
+ }
+ }
+ }
+ ```
+
+ changes to:
+
+ ```json
+ {
+ "remote_addr": "127.0.0.1",
+ "plugins": {
+ "mqtt-proxy": {
+ "protocol_name": "MQTT",
+ "protocol_level": 4
+ }
+ },
+ "upstream": {
+ "type": "chash",
+ "key": "mqtt_client_id",
+ "nodes": [
+ {
+ "host": "127.0.0.1",
+ "port": 1980,
+ "weight": 1
+ }
+ ]
+ }
+ }
+ ```
+
+5. `max_retry_times` and `retry_interval` fields from the
[syslog](./plugins/syslog.md) plugin are replaced `max_retry_count` and
`retry_delay` respectively. The configuration below:
+
+ ```json
+ {
+ "plugins":{
+ "syslog":{
+ "max_retry_times":1,
+ "retry_interval":1,
+ ... // other configuration
+ }
+ }
+ }
+ ```
- If such a data structure of proxy-rewrite plugin exists in ETCD
+ changes to:
- ```json
- {
- "plugins":{
- "proxy-rewrite":{
- "scheme":"https",
- ... // other configuration
- }
- },
- "upstream":{
- "nodes":{
- "127.0.0.1:1983":1
- },
- "type":"roundrobin"
- },
- "uri":"/hello"
- }
- ```
+ ```json
+ {
+ "plugins":{
+ "syslog":{
+ "max_retry_count":1,
+ "retry_delay":1,
+ ... // other configuration
+ }
+ }
+ }
+ ```
- In 3.0.0, the data structure of this plugin should be transformed to
+6. `scheme` attribute has been removed from the
[proxy-rewrite](./plugins/proxy-rewrite.md) plugin and has been added to the
upstream. The configuration below:
- ```json
- {
+ ```json
+ {
"plugins":{
"proxy-rewrite":{
+ "scheme":"https",
... // other configuration
}
},
"upstream":{
- "scheme":"https",
"nodes":{
"127.0.0.1:1983":1
},
"type":"roundrobin"
},
"uri":"/hello"
- }
- ```
-
-#### Admin API
-
-We have made some tweaks to the Admin API that are designed to make it easier
to use and more in line with RESTful design ideas.
-
-Adjustment content:
-
- * When operating resources (both single resources and list resources), the
`count`, `action` and `node` fields in the response body are removed and the
contents of `node` are moved up to the root of the response body
-
- In version 2.x, the response format for querying `/apisix/admin/routes/1`
via the Admin API is
-
- ```json
- {
- "count":1,
- "action":"get",
- "node":{
- "key":"\/apisix\/routes\/1",
- "value":{
- ... // content
- }
- }
- }
- ```
-
- In 3.0.0, the response format for querying the `/apisix/admin/routes/1`
resource via the Admin API is
-
- ```json
- {
- "key":"\/apisix\/routes\/1",
- "value":{
- ... // content
- }
- }
- ```
-
- * When querying the list resources, delete the `dir` field, add a new `list`
field to store the data of the list resources, and add a new `total` field to
store the total number of list resources
-
- In version 2.x, the response format for querying `/apisix/admin/routes` via
the Admin API is
-
- ```json
- {
- "action":"get",
- "count":2,
- "node":{
- "key":"\/apisix\/routes",
- "nodes":[
- {
- "key":"\/apisix\/routes\/1",
- "value":{
- ... // content
- }
- },
- {
- "key":"\/apisix\/routes\/2",
- "value":{
- ... // content
- }
- }
- ],
- "dir":true
- }
- }
- ```
-
- In 3.0.0, the response format for querying the `/apisix/admin/routes`
resource via the Admin API is
-
- ```json
- {
- "list":[
- {
- "key":"\/apisix\/routes\/1",
- "value":{
- ... // content
- }
-
- },
- {
- "key":"\/apisix\/routes\/2",
- "value":{
- ... // content
- }
- }
- ],
- "total":2
- }
- ```
+ }
+ ```
- * Adjust the request path of the ssl resource from `/apisix/admin/ssl/{id}`
to `/apisix/admin/ssls/{id}`
+ changes to:
- In version 2.x, operating with ssl resources via the Admin API
+ ```json
+ {
+ "plugins":{
+ "proxy-rewrite":{
+ ... // other configuration
+ }
+ },
+ "upstream":{
+ "scheme":"https",
+ "nodes":{
+ "127.0.0.1:1983":1
+ },
+ "type":"roundrobin"
+ },
+ "uri":"/hello"
+ }
+ ```
- ```shell
- curl -i http://{apisix_listen_address}/apisix/admin/ssl/{id}
- ```
+## API
- In 3.0.0, operating with ssl resources via the Admin API
+Changes have been made to the Admin API to make it easier to use and be more
RESTful.
- ```shell
- curl -i http://{apisix_listen_address}/apisix/admin/ssls/{id}
- ```
+The following changes have been made:
- * Adjust the request path of the proto resource from
`/apisix/admin/proto/{id}` to `/apisix/admin/protos/{id}`
+1. The `count`, `action`, and `node` fields in the response body when querying
resources (single and list) are removed and the fields in `node` are moved up
to the root of the response body. For example, if you query the
`/apisix/admin/routes/1` endpoint of the Admin API in version 2.15.x, you get
the response:
- In version 2.x, operating with proto resources via the Admin API
+ ```json
+ {
+ "count":1,
+ "action":"get",
+ "node":{
+ "key":"\/apisix\/routes\/1",
+ "value":{
+ ... // content
+ }
+ }
+ }
+ ```
+
+ In 3.0.0, this response body is changes to:
+
+ ```json
+ {
+ "key":"\/apisix\/routes\/1",
+ "value":{
+ ... // content
+ }
+ }
+ ```
+
+2. When querying list resources, the `dir` field is removed from the response
body, a `list` field to store the data of the list resources and a `total`
field to show the total number of list resources are added. For example, if you
query the `/apisix/admin/routes` endpoint of the Admin API in version 2.15.x,
you get the response:
+
+ ```json
+ {
+ "action":"get",
+ "count":2,
+ "node":{
+ "key":"\/apisix\/routes",
+ "nodes":[
+ {
+ "key":"\/apisix\/routes\/1",
+ "value":{
+ ... // content
+ }
+ },
+ {
+ "key":"\/apisix\/routes\/2",
+ "value":{
+ ... // content
+ }
+ }
+ ],
+ "dir":true
+ }
+ }
+ ```
+
+ In 3.0.0, the response body is:
+
+ ```json
+ {
+ "list":[
+ {
+ "key":"\/apisix\/routes\/1",
+ "value":{
+ ... // content
+ }
- ```shell
- curl -i http://{apisix_listen_address}/apisix/admin/proto/{id}
- ```
+ },
+ {
+ "key":"\/apisix\/routes\/2",
+ "value":{
+ ... // content
+ }
+ }
+ ],
+ "total":2
+ }
+ ```
- In 3.0.0, operating with proto resources via the Admin API
+3. The endpoint to SSL resource is changed from `/apisix/admin/ssl/{id}` to
`/apisix/admin/ssls/{id}`.
- ```shell
- curl -i http://{apisix_listen_address}/apisix/admin/protos/{id}
- ```
+4. The endpoint to Proto resource is changed from `/apisix/admin/proto/{id}`
to `/apisix/admin/protos/{id}`.
-We also adjusted the Admin API port to 9180.
+5. Admin API port is set to `9180` by default.
