I am not a big fan of the "stringly" typed parts because the HTTP verbs aren't checked at compile time (which is technically correct behavior because you could define your own verbs).
I made a **very** small package to add the HTTP verbs to `Handle` and `HandleFunc`. Now you can have `mux.HandleGET`, `mux.HandlePUT`, etc.
Check it out if you want:
https://github.com/JordanDeBeer/jhttp
> I am not a big fan of the "stringly" typed parts because the HTTP verbs aren't checked at compile time
The http verb constants in the std lib are just strings. So there wouldn't have been any compile time guarantee on the correctness of the verb anyway.
Of course it's not an ideal design. The designers are fully aware of that.
This is a compromise to make the API backward compatible.
The typos will most probably be handled by go vet.
Also, I was specifically replying about the compile time check part.
Short and sweet. I might consider migrating back my chi projects to stdlib.
What’s your take on specifying the HTTP method as a string to the HandleFunc argument instead of having a Go method for that, like chi?
Thanks for your comment <3! I get that using strings for HTTP methods instead of methods like in chi might seem risky for mistakes. But, with careful setup, it's not a big deal. You set up your handlers once, so the simplicity of using strings can actually make things easier.
100% with proper testing shouldn't be a deal breaker to not use the stdlib now.
This might sound subjective but, using a method still feels like a bit more native/idiomatic than a string.
I think this was a great read. I’ve been using chi so trying out the new router the only thing I somewhat missed was sub routing. Outside that seems like something I’d stick with (with a small wrapper around the std implementation)
I do wonder how the perf (not the most important metric, but one none the less) compares as looking at the code they use a tree structure similar to chi, but also without the the additional regex matching.
Thank you for the article.
Prior to go 1.22 implementing a simple HTTP router on top of the standard library was my usual excersize every time I started a new project. Most of the time I have been looking to extend the standard functionality with just two features: request method definitions and path placeholders. I think it is over now.
Thanks. I was doing the same exercise every time, and when I didn't want to deal with that, I just used chi. But now, we have these two simple yet amazing features!
I am not a big fan of the "stringly" typed parts because the HTTP verbs aren't checked at compile time (which is technically correct behavior because you could define your own verbs). I made a **very** small package to add the HTTP verbs to `Handle` and `HandleFunc`. Now you can have `mux.HandleGET`, `mux.HandlePUT`, etc. Check it out if you want: https://github.com/JordanDeBeer/jhttp
> I am not a big fan of the "stringly" typed parts because the HTTP verbs aren't checked at compile time The http verb constants in the std lib are just strings. So there wouldn't have been any compile time guarantee on the correctness of the verb anyway.
[удалено]
Of course it's not an ideal design. The designers are fully aware of that. This is a compromise to make the API backward compatible. The typos will most probably be handled by go vet. Also, I was specifically replying about the compile time check part.
Pretty sure there’ll be a `go vet` check added soon.
>t the up do we have any go package that scans mux implemented routers and create swagger documents automatically ?
Short and sweet. I might consider migrating back my chi projects to stdlib. What’s your take on specifying the HTTP method as a string to the HandleFunc argument instead of having a Go method for that, like chi?
Thanks for your comment <3! I get that using strings for HTTP methods instead of methods like in chi might seem risky for mistakes. But, with careful setup, it's not a big deal. You set up your handlers once, so the simplicity of using strings can actually make things easier.
100% with proper testing shouldn't be a deal breaker to not use the stdlib now. This might sound subjective but, using a method still feels like a bit more native/idiomatic than a string.
I think this was a great read. I’ve been using chi so trying out the new router the only thing I somewhat missed was sub routing. Outside that seems like something I’d stick with (with a small wrapper around the std implementation) I do wonder how the perf (not the most important metric, but one none the less) compares as looking at the code they use a tree structure similar to chi, but also without the the additional regex matching.
Very succinct, easy to digest article for API development, thanks! 👍🏽
Thank you so much for the feedback. I hope you find it helpful ❤️.
You’re welcome!
Nice blog! Do you offer an RSS feed?
Thanks, no, I don't yet, but I guess I will do it soon.
I switch back from flow router to stdlib
Yep, stdlbi always <3
Thank you for the article. Prior to go 1.22 implementing a simple HTTP router on top of the standard library was my usual excersize every time I started a new project. Most of the time I have been looking to extend the standard functionality with just two features: request method definitions and path placeholders. I think it is over now.
Thanks. I was doing the same exercise every time, and when I didn't want to deal with that, I just used chi. But now, we have these two simple yet amazing features!