Skip to main content

Version: 3.9.0


In this document, you will learn the basic concept of routes in APISIX, different routing options APISIX offers, as well as drawbacks and solutions to repetitive route configurations.

Explore additional resources at the end of the document for more information on related topics.


Routes define paths to upstream services. In APISIX, a route object is used to create a route when APISIX operates on the application layer, as opposed to a stream route object, which is used to create a route when APISIX functions as a stream proxy operating on the transport layer. Routes are responsible for matching client requests based on configured rules, loading and executing the corresponding plugins, and forwarding requests to the specified upstream endpoints.

A simple route can be set up with a path-matching URI and a corresponding upstream address. The diagram below shows an example of users sending two HTTP requests to the APISIX API gateway, which are forwarded accordingly per the configured rules in routes:

Routes Diagram

Routes are often configured with plugins as well. For example, configuring the rate-limit plugin in a route will enable rate-limiting effects.

Routing Options

APISIX offers three HTTP routing options:

  1. radixtree_host_uri routes requests by hosts and URI paths. It can be used to route north-south traffic between clients and servers.

  2. radixtree_uri routes requests by URI paths. It can be used to route east-west traffic, such as between microservices.

  3. radixtree_uri_with_parameter enhances on radixtree_uri to support the use of parameter in path matching.

These routing options can be configured in conf/config.yaml under apisix.router.http.

Routes, Upstreams, and Services

While routes are essential in defining the paths of traffic flows, there are drawbacks to repetitive route configurations (i.e. hard coding the same upstream addresses or plugin names for a group of routes). During the time of updates, the repetitive field(s) of these routes will need to be traversed and updated one by one. Configurations like this increase a lot of maintenance costs as a result, especially in large-scale systems with many routes.

To address this issue, Upstreams and Services were designed to abstract away repetitive information and reduce redundancies, following the DRY principle.

Additional Resource(s) Logo

API Management for Modern Architectures with Edge, API Gateway, Kubernetes, and Service Mesh.


API7 Cloud

SOC2 Type IRed Herring

Copyright © APISEVEN Ltd. 2019 – 2024. Apache, Apache APISIX, APISIX, and associated open source project names are trademarks of the

Apache Software Foundation