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 are often configured with plugins as well. For example, configuring the rate-limit plugin in a route will enable rate-limiting effects.
APISIX offers three HTTP routing options:
radixtree_host_uriroutes requests by hosts and URI paths. It can be used to route north-south traffic between clients and servers.
radixtree_uriroutes requests by URI paths. It can be used to route east-west traffic, such as between microservices.
radixtree_urito support the use of parameter in path matching.
These routing options can be configured in
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.