httpstatus crate provides a list of HTTP response status codes and their corresponding status classes and reason phrases.
Repository https://github.com/yaa110/rust-httpstatus
crates-io https://crates.io/crates/httpstatus
1 Like
Just out of curiosity, how does httpstatus differ from the StatusCode type from the http crate?
1 Like
Hopefully we don't go the "javascript" way of having crates for small functionalities.
1 Like
I think it is better to have atomic crates (with small functionalities) rather than a big crate (with surplus functionalities). The only difference between these two crates (+ the different implementations) is the return type of conversion methods from and to u16.
That's arguably not a bad thing. In my opinion it's a lot better to make a library which does one thing, and does it well, than having a small number of monolithic libraries (e.g. C++'s boost). Compilation times also benefit because separate crates can be compiled in parallel, plus it allows other crates to build on existing things instead of reinventing the wheel every time.
3 Likes
True. but that one thing is taken too far. The "atom" of a crate should normally be a bit higher than those "ultra-modular crates".
Having very small crates increases the amount of dependencies you have which could result in unexpected behaviour if all are not updated around the same time.
Also the whole point of a crate is to save "dev time" that you would normally take to implement the feature on your own. Having micro-level crates defeats the purpose.
you know, hyper has implemented its own StatusCode module, Rocket also has implemented a module for this purpose and you might find many others reinventing the wheel for this sort of crates which are the simplest part of the main project.
I wonder how an increase in the amount of dependencies could cause an unexpected behavior.
3 Likes
The more crates you have, the higher is the chance to have version conflicts, bugs, vulnerabilities, waiting for authors to fix them (assuming they are all maintained separately or you use different crates from different authors). It may not be evident right now in Rust community, but it normally is an interpreted world. Either way i think this might not be the best place for this discussion.
This alone would be reason enough for me to have a crate like this.
@yaa110: Have you approached the hyper and Rocket teams to discuss standardising on a common crate? (possibly yours)
Your good crate could be even cooler if community uptake becomes better.
3 Likes
I think we've already had, and IMHO it's fantastic. -> Small dependencies in rust? do or don't?
3 Likes
Yeah but that still doesn't solve the other issues related to maintaining smaller crates and having large list of dependencies
To avoid sidetracking the http discussion, I humbly suggest we continue the small-vs-large crate discussion in this new topic.
For HTPP, I personally believe the discussion is trivial. It would be just annoying to have multiple incompatible http types (hyper::StatusCode, rocket::http, Jules::LazyPartialImplementation, etc.). All the conversion code everyone would have to write would be a bigger annoyance.
Let's make this topic about what should and shouldn't be in http, and move the principles discussion off-thread
4 Likes