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...
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.
Certainly it's technically a breaking change, but there's huge difference between making all existing usage of the mux interface incompatible with the new changes, and only making obviously incorrect and buggy usages of the interface incompatible.
This has always resulted in a panic[0].
[0]: https://cs.opensource.google/go/go/+/refs/tags/go1.19:src/ne...
That wouldn’t break compatibility
I don't really see an issue in treating it as if it was just `Request-URI` (in RFC2616 terms) with some parameter magic, and became a Request-Line-resembling `[ Method SP ] Request-URI`, which is fully backwards-compatible and isn't exactly surprising to anyone. I think it's pretty much obvious what it does even if one never sees the documentation.
And given that `Method` is either one of a few predefined constants or `extension-method = token`, and `token` excludes whitespace, slashes and all sort of brackets I don't think there's a chance of confusion or misparsing there, even for weirdest custom methods.
The compiler via a method call or parameter can capture this constraint in a pretty straight forward way. I'm not sure why an API would give that up
With this proposal if you already have an app using mux, you can change one line and you have app using new mux which you can then evolve to take advantage of additional capabilities.
With new name you have to rename all your codebase.
Not to mention that writing a wrapper with an API to your liking is few trivial lines of code so this is bike shedding at its finest.
In my head it's as if we did this:
http.Segments("foo", "bar", http.Param("barID"), "baz")
/foo/bar/:barID/baz
I sure don't.
And those that do probably aren't careful about HTTP headers either.
So in practice this an improvement for most.
And if you don't like how it works, there are plenty of alternatives to use.
Arguably this is more correct that letting the users declare a separate Handler that can neither guarantee the same headers as the the GET Handler not guarantee that the body is not sent the response.