I have seen a lot of posts talk about building your own MUX in Go, one of the many examples is here (http://thenewstack.io/building-a-web-server-in-go/).
When should you use the default versus defining your own? The Go docs and none of the blog posts say why you should use one over the other.
分享 There are two downsides to the builtin mux:
If you need info from the url (for example id in /users/:id) you have to do it manually:
http.HandleFunc("/users/", func(res http.ResponseWriter, req *http.Request) {
id := strings.SplitN(req.URL.Path, "/", 3)[2]
})
Which is cumbersome.
The default server mux is not the fastest.
Consider the conclusions from this benchmark:
First of all, there is no reason to use net/http's default ServeMux, which is very limited and does not have especially good performance. There are enough alternatives coming in every flavor, choose the one you like best.
So really its only advantage is that everyone already has it since it's included in net/http.
Lately I've been moving in the direction of avoiding the default http.Handle and http.HandleFunc functions and defining an explicit http.Handler instead, which is then handed to ListenAndServe. (instead of nil:
handler := http.NewServeMux()
handler.Handle("/whatever", ...)
http.ListenAndServe(80, handler)
Newer developers find the distinction between http.Handle and http.HandleFunc subtle and confusing so I think it's worth understanding the http.Handler concept up front. A mux is just another kind of http.Handler (one that routes requests to other http.Handlers) and that reality is hidden away when you rely on the DefaultServeMux.
分享
