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

Open
AyushG3112 opened this Issue Nov 27, 2017 · 6 comments

Comments

Projects
None yet
5 participants
@AyushG3112

AyushG3112 commented Nov 27, 2017

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 a map[string]string be allowed?

@mvdan mvdan changed the title from Feature Request - Parameterized Routes in http.Handle to net/http: parameterized Routes in Handle Nov 27, 2017

@mvdan

This comment has been minimized.

Member

mvdan commented Nov 27, 2017

As far as I know, http.ServeMux is a simple router and should stay that way. If you want more advanced features, there are a ton of routers out there that you can use, such as https://github.com/go-chi/chi and https://github.com/gorilla/mux.

@AyushG3112

This comment has been minimized.

AyushG3112 commented Nov 27, 2017

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

@mvdan

This comment has been minimized.

Member

mvdan commented Nov 27, 2017

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.

@bradfitz

This comment has been minimized.

Member

bradfitz commented Nov 27, 2017

Sorry, http.ServeMux's feature set is frozen, at least for Go 1.

I'll leave this open to consider for later.

@xgfone

This comment has been minimized.

xgfone commented Dec 11, 2017

I hope to add this feature in Go2.

If the std library supplies it, I don't need to import the third-party router.

@tj

This comment has been minimized.

tj commented Mar 15, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment