17

I was wondering if I should create a new ServeMux and register it to the http.Server or should I invoke http.HandleFunc and http.Handler directly?

I think the route with a ServeMux is better because http.HandleFunc obviously messes with the global state of the HTTP package, which is considered bad practice in Go. However, in many tutorials, even the official ones, I often see the http.HandleFunc route being used.

This makes me wonder: why should one use http.HandleFunc when there is a ServeMux? I know that ServeMux has some advantages (e.g. you can nest it without repeating the prefix all the time) but I wonder why I should ever choose http.HandleFunc over Multiplexer, especially since HandleFunc uses a ServeMux internally.

Edit: as promised in the comments, I've asked to deprecate the additional (and useless IMO functions) on Golang-dev and they said no (well, on person said no). Here is the link.

Matt3o12
  • 4,192
  • 6
  • 32
  • 47
  • (I also wanted to say that this is a good question, and a useful one for others in the future, since it has come up before) – elithrar Mar 27 '16 at 15:29
  • elithrar: that's why I asked it here. I couldn't find anything on Google. Imo, `http.HandleFunc` and `http.Handle` should be deprecated, then. Using a `Mux` and `Server` only adds 2 more lines and ambiguity is always bad, especially if the more obvious way is the "bad way". – Matt3o12 Mar 27 '16 at 15:32
  • The Go1 compatibility promise doesn't allow removal, so we're 'stuck' with them until "2.0" (which is a long way off - years). – elithrar Mar 27 '16 at 15:39
  • elithrar: I can't find anything about deprecation in the compatibility promise. It would still be available and work as it does now (at least until 2.0) but beginners will stay away from it. – Matt3o12 Mar 27 '16 at 15:42
  • The only way to deprecate is a documentation note. Go doesn't have the concept of "warnings" (from the compiler), so the effectiveness would be pretty minimal. You're welcome to propose adding documentation to these methods on golang-dev. – elithrar Mar 27 '16 at 15:50
  • I will do! I think do a documentation note would do a lot! The first thing I did when I notice there are two methods was reading the docs again. – Matt3o12 Mar 27 '16 at 15:52

1 Answers1

10

You're on the right track: you should prefer to instantiate your own ServeMux, for the reasons you've outlined.

Using DefaultServeMux also runs the risk of exposing profiling endpoints when using net/http/pprof, since those are attached to the DefaultServeMux.

http.Handle|HandleFunc are convenience methods, and perhaps useful for keeping the boilerplate in example code down, but creating a ServeMux gives you the ability to wrap it, nest it within another, export it from a constructor, etc.

elithrar
  • 23,364
  • 10
  • 85
  • 104