前言
在之前的文章中，我们用Go的标准库来实现了服务器，JSON渲染重构为辅助函数，使特定的路由处理程序相当简洁。
我们剩下的问题是路径路由逻辑，这是所有编写无依赖HTTP服务器的人都会遇到的问题，除非服务器只处理一到两个路由，否则组织路由器代码是冗长和困难的。
高级路由
首先的想法是抽象路由，可能使用一组函数或带有方法的数据类型，有许多有趣的临时方法可以做到这一点，Go生态系统中有许多功能强大且使用良好的三方路由包可以为做这件事。
我们再回顾一下设计的服务器路由：
POST /page/ : create a page, returns ID
GET /page/<pageid> : returns a single page by ID
GET /page/ : returns all pages
DELETE /page/<pageid> : delete a page by ID
PUT /page/<pageid> : update a page by ID
GET /tag/<tagname> : returns list of pages with this tag
GET /due/<yy>/<mm>/<dd> : returns list of pages due by this date
我们可以做几件事来使路由更符合观感：
- 添加一种方法来为同一路由上的不同方法设置单独的处理程序。例如，/page/的POST应该转到一个处理程序，GET /page/到另一个处理程序，等等。
- 添加一种“更深”匹配的方法；例如，我们应该可以说/page/进入一个处理程序，而 /page/使用数字ID进入另一个处理程序。
- 当我们这样做时，匹配器应该只从/page/中提取数字ID并以某种方便的方式将其传递给处理程序。
由于HTTP处理程序的可组合性，在Go中编写自定义路由器非常简单，例如最流行的第三方方路由包之一：gorilla/mux。
gorilla/mux实现的服务器
gorilla/mux是最久的流行Go HTTP路由器之一，根据文档，名称mux代表“HTTP请求多路复用器”（与标准库中的含义相同）。
因为它是一个目标明确的包，所以它的使用相当简单，以下是路由的定义方式：
router := mux.NewRouter()
router.StrictSlash(true)
server := NewPageServer()
router.HandleFunc("/page/", server.createPageHandler).Methods("POST")
router.HandleFunc("/page/", server.getAllPagesHandler).Methods("GET")
router.HandleFunc("/page/", server.deleteAllPagesHandler).Methods("DELETE")
router.HandleFunc("/page/", server.updatePageHandler).Methods("PUT")
router.HandleFunc("/page/{id:[0-9]+}/", server.getPageHandler).Methods("GET")
router.HandleFunc("/page/{id:[0-9]+}/", server.deletePageHandler).Methods("DELETE")
router.HandleFunc("/tag/", server.tagHandler).Methods("GET")
router.HandleFunc("/due/", server.dueHandler).Methods("GET")
通过将方法调用附加到路由上，我们可以轻松地将同一路径上的不同方法定向到不同的处理程序。路径中的模式匹配（使用正则表达式语法）让我们可以轻松地区分顶级路由定义中的/page/和/page/。
我们来看看getPageHandler：
func (p *PageServer) getPageHandler(w http.ResponseWriter, r *http.Request) {
log.Printf("handling get page at %s\n", r.URL.Path)
// Here and elsewhere, not checking error of Atoi because the router only
// matches the [0-9]+ regex.
id, _ := strconv.Atoi(mux.Vars(r)["id"])
ret, err := p.store.GetPage(id)
if err != nil {
http.Error(w, err.Error(), http.StatusNotFound)
return
}
renderJSON(w, ret)
}
在路由定义中，路由/page/{id:[0-9]+}/定义了解析路径的正则表达式，但也将标识符部分分配给“id”。这个“变量”可以通过在请求上调用mux.Vars来访问。
方法对比
为了理解GET /page/路由在我们的原始服务器中是如何处理的，必须采用以下代码阅读路径：
而这是使用gorilla/mux时的路径：
除了可以跳过的步骤更少之外，要阅读的代码也大大减少了，从代码可读性的角度来看，使用gorilla/mux的路径定义简短明了，阅读者很清楚这是如何工作的。另一个优势是，我们现在可以在一个地方一目了然地轻松查看所有路由。事实上，路由配置代码现在看起来与我们非正式的REST API定义非常相似。
像gorilla/mux这样的包，因为它们是一个精密工具，他们只做一件事，而且做得很好，而且他们不会“感染”整个程序，使他们以后难以删除或替换。如果我们检查这部分的服务器代码，我们会注意到使用gorilla/mux的部分仅限于相对较少的代码行。如果我们在项目生命周期的后期发现这个包有一个致命的限制，用另一个路由包（或手动版本）替换它应该是相当简单的。
