1, 3, and 4 are already there, they're just a part of Hyper, not Axum/Warp/Rocket. 2 is basically the thing that Axum/Warp/Rocket provide. Hyper is kinda like net/http and Axum/Warp/Rocket are more feature rich. The thing is, they're super early. They don't remind me of the pared-down quality simplicity of the Gorilla Toolkit or even the feature paradise of Gin.
Honestly it a lot of the Rust http frameworks strike me as eerily similar to either Falcore or Revel. Falcore was a very early Go http application framework built by ngmoco, a now-defunct game company. Falcore didn't really gain a lot of traction, partially because it provided abstractions that weren't very ergonomic. It's whole thing was that the core abstraction was a modular pipeline. https://github.com/ngmoco/falcore
I think most people know Revel, it's a little less obscure. It's philosophically the precursor to Gin.
The examples showcased by Axum and co. are the "ergonomic simple cases" and it's easy to morph what's provided into any flavor you personally prefer with as many `impl`s and types. Here's[0] my jam rn.
that’s not what the Axum example does. The function you’re linking turns an opaque run of bytes into an http request object. What the Axum example does is turn an http request object into a value of some other type T.
1. A request type and an associated response type
2. Impls for converting an HTTP request into the request type, and the reverse for response
3. A server type with an impl for handling the request
4. A client type with an impl for sending the request
The remaining challenge is making all this ergonomic for the simple cases.