Better HTTP server routing in Go 1.22
eli.thegreenplace.net
Better HTTP server routing in Go 1.22
1–10 of 236 posts
Re: Better HTTP server routing in Go 1.22
#2Will this finally end the eternal golang http router bikeshedding?
Re: Better HTTP server routing in Go 1.22
#3As I commented[1] I think the syntax is flawed in the proposal.
You need to weirdly create a magic string to define your handler. Why not make it an actual argument, then using already existing constants is easier.
[1] https://github.com/golang/go/issues/61410#issuecomment-16580...
Re: Better HTTP server routing in Go 1.22
#4Will this finally end the eternal golang http router bikeshedding?
lol no, will start the proliferation of more different abstractions over it
Re: Better HTTP server routing in Go 1.22
#5Forcing a panic when 2 routes are matched seems counter intuitive to me (versus, idk, every other web framework which uses the first-to-be-registered route that matches).
Are there go-specific reasons for that? The edge case of "you might register HTTP routes in a bunch of places and it's harder to find that if multiple routes match" seems like something that be worked around with tooling.
I've (ab)used the behavior of "first to be matched wins" a ton in my career - there's been a bunch of "business case" times when I've needed like `/foo/bar` to be one registered route, and `/foo/{id}` to be another.
Re: Better HTTP server routing in Go 1.22
#6I would far rather the overlapping path’s just match in the order they were defined rather than panic.
In their example here, had they defined the `/task/0/{action}/` path before the wildcard path, my expectation would have been for that to match first. This would allow for handlers for special cases to easily be defined.
I’d far rather things just do what I say than fail in “helpful” ways. Smells really funny and not very Go.
Re: Better HTTP server routing in Go 1.22
#7Great syntax. I didn't use any third-party routers, because implementing my own router is not a big deal, but this is just great.
Re: Better HTTP server routing in Go 1.22
#8As I commented[1] I think the syntax is flawed in the proposal. You need to weirdly create a magic string to define your handler. Why not make it an actual argument, then using already existing constants is easier. [1] https://github.com/golang/go/issues/61410#issuecomment-16580...
Isn’t that just a consequence of Go’s backwards compatibility guarantee?
Adding new arguments to the Mux interface would break existing code, given the method signature can’t be changed, these magic strings seem like a reasonable compromise. It not like HTTP verbs are going to change anytime soon, and it’s trivial to validate them during register, or via static analysis. So I’m not sure what value the use of constants would bring, especially if it either broke backwards compatibility, or forced the creation of a new, but slightly different mux API that would have to live in parallel with the old API forever.
Re: Better HTTP server routing in Go 1.22
#9Go is not my main tool but I've used Gin which goes like this:
router.GET("/", func(context *gin.Context) {
...
}
Re: Better HTTP server routing in Go 1.22
#10Forcing a panic when 2 routes are matched seems counter intuitive to me (versus, idk, every other web framework which uses the first-to-be-registered route that matches). Are there go-specific reasons for that? The edge case of "you might register HTTP routes in a bunch of places and it's harder to find that if multiple routes match" seems like something that be worked around with tooling. I've (ab)used the behavior…
I believe it allows `/foo/bar` and `/foo/{id}` as the first one is more specific and has precedence. This looks fine to me.
Looks like it will panic in case you have `/foo/{id}/delete` and `/foo/bar/{action}`. /foo/bar/delete will match both, none is more specific so it panics. Feels reasonable. Having a first one wins precedence might be better though.