New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
net/http: parameterized Routes in Handle #22887
Comments
As far as I know, |
I would agree if this was a use case which is not encountered often enough. While I can use 3rd party routers, they do a lot more stuff under the wraps, causing some overhead. I would prefer not to go through that if possible. Although if you or anyone could provide a router/Mux with comparable runtime performance, I would appreciate that too |
A feature that seems fundamental to one may seem useless to another. You can't have a router that is both useful and free of bloat to everyone's standards. Have you measured performance on third-party routers to be orders of magnitude slower than that of ServeMux? I would be surprised if it were the case, or if it even mattered in most use cases. I also suspect that the introduction of path arguments and maps would incur extra work and a slow-down no matter what. As said before, I don't know where the line is drawn for ServeMux. I'm simply trying to point out that adding more features can be a slippery slope, and you already have good alternatives elsewhere. |
Sorry, http.ServeMux's feature set is frozen, at least for Go 1. I'll leave this open to consider for later. |
I hope to add this feature in Go2. If the std library supplies it, I don't need to import the third-party router. |
A router in stdlib would be sweet IMHO, they're honestly all pretty much the same, barring internal performance differences etc, but I guess it's not hard to make a case for "just use a third-party router" either :D. |
You think a simple util would help? http.HandleFunc("/users/", func (w http.ResponseWriter, r *http.Request) {
a := r.VarPath(0) // given "/users/123/something", a == "users"
b := r.VarPath(1) // given "/users/123/something", b == "123"
c := r.VarPath(2) // given "/users/123/something", c == "something"
}) At least you can manually check the value inside a handler and call another handler, and everything continues simple. |
This is a feature request and not a bug.
As is a basic requirement during path matching, can defining a path parameter be allowed in
http.Handle
and getting the value of the passed parameter in the request as amap[string]string
be allowed?The text was updated successfully, but these errors were encountered: