Routes

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.

Overview

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.

Router Options

APISIX offers three HTTP routing options:

1. radixtree_host_uri routes requests by hosts and URI paths, prioritizing hostnames over URI paths during matching. This is the default setting. It can be used to route north-south traffic between clients and servers. This is the default routing option.

2. radixtree_uri routes requests by hosts and URI paths, prioritizing URI paths over hostnames during matching. It can be used to route east-west traffic, such as between microservices.

3. radixtree_uri_with_parameter enhances 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. For more information, see Router Options.

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)

• Getting Started - Configure Routes
• Key Concepts - Stream Routes
• Admin API - Route