GF Framework Routing Control-powerful, flexible and efficient

This is a creation in Article, where the information may have evolved or changed.

Article Source: http://gf.johng.cn/494375

GF Framework provides a very powerful self-built routing control function, supports popular naming matching rules and fuzzy matching rules, and provides excellent priority management mechanism. The following is an example of using route control in a service registration:

package mainimport "gitee.com/johng/gf/g/net/ghttp"func main() {    s := ghttp.GetServer()    s.BindHandler("/:name", func(r *ghttp.Request){        r.Response.Writeln("pattern: /:name match")        r.Response.Writeln(r.Get("name"))    })    s.BindHandler("/:name/:action", func(r *ghttp.Request){        r.Response.Writeln("pattern: /:name/:action match")        r.Response.Writeln(r.Get("name"))        r.Response.Writeln(r.Get("action"))    })    s.BindHandler("/:name/*any", func(r *ghttp.Request){        r.Response.Writeln("pattern: /:name/*any match")        r.Response.Writeln(r.Get("name"))        r.Response.Writeln(r.Get("any"))    })    s.SetPort(8199)    s.Run()}

Where /:name/:action the routing rules /:name/*any have higher precedence, so when accessed, the http://127.0.0.1:8199/john/info result is:

pattern: /:name/:action matchjohninfo

There are two types of routing rules: static routing Rules and dynamic routing rules.

Static routing Rules

A static routing rule is a routing rule without any naming matching and fuzzy matching, which is a deterministic URI address, for example: /user/info ,, /src/path/file and /member/register so on. static routing rules are very efficient in service registration and service retrieval because there is no need for additional prioritization and regular rule judgments, the underlying data structure is just a hash table, and the time complexity of registration and Retrieval is O (1). Therefore, in real-world project development, it is recommended that static routing rules be used wherever static routing rules are used.

Dynamic routing Rules

There are two kinds of dynamic routing rules: named matching rules and fuzzy matching rules. The underlying data structure of dynamic routing consists of a tree hash table and a linked list of leaf nodes, and a tree hash table facilitates efficient hierarchical matching of URIs; the list of leaf nodes is used for priority control, and the routing rules at the same level are sorted by priority, with high priority rules ranked in the list header. The underlying routing rules match the request URI with regular expressions, and the caching mechanism is fully utilized to perform efficiently.

Naming matching rules

Use the :name method to match ( name for a custom matching name), to name and match the parameters of the specified level of the URI (similar to regular), and the ([\w\.\-]+) corresponding matching parameters are parsed into the get parameters and passed to the registered service for use.

Match Example 1:

rule: /user/:user/user/john                match/user/you                 match/user/john/profile        no match/user/                    no match

Match Example 2:

rule: /:name/action/john/name                no match/john/action              match/smith/info               no match/smith/info/age           no match/smith/action             match

Match Example 3:

rule: /:name/:action/john/name                match/john/info                match/smith/info               match/smith/info/age           no match/smith/action/del         no match

Fuzzy matching rules

Used to *any match ( any for a custom match name), the parameters after the URI specified position are fuzzy matched (similar to regular (.*) ), and the matching parameters are resolved to the get parameters and passed to the registered service for use.

Match Example 1:

rule: /src/*path/src/                     match/src/somefile.go          match/src/subdir/somefile.go   match/user/                    no match/user/john                no match

Match Example 2:

rule: /src/*path/:action/src/                     no match/src/somefile.go          no match/src/somefile.go/del      match/src/subdir/file.go/del   match

Match Example 3:

rule: /src/*path/show/src/                     no match/src/somefile.go          no match/src/somefile.go/del      no match/src/somefile.go/show     match/src/subdir/file.go/show  match

Routing Priority Control

Priority control is the main two-point factor:

1. the deeper the hierarchy, the higher the rule priority ;
2. The naming match is higher than the fuzzy matching priority ;

Let's look at the example (the rule priority on the left is higher than the right):

/:name                   >            /*any/user/name               >            /user/:action/:name/info              >            /:name/:action/:name/:action           >            /:name/*action/src/path/del            >            /src/path/src/path/del            >            /src/path/:action/src/path/*any           >            /src/path

In the example at the beginning of this section, the precedence control is already well described, and here is no longer an example.

In addition, it should be noted that the static matching rule / is a special rule, the lowest priority, when any other rules can not match, will automatically match under the rule, it can be seen as a global rule. For example, when the system has three routing rules, when the / /user /:name application side requests, will be caught by the routing rules, when the /user/register / application side of the request, will be /user caught by the routing rules, /user when the application side of the request, will be /src routed rule /:namecapture.