mjkillough/aitch

aitch is a simple, lightweight toolkit for building HTTP servers in Rust, loosely based on Go's net/http.

aitch's Issues

Make the logging look prettier

Emojis and colour!

Docs

Write README

Should the error type be Box<Error>?

We currently define aitch::Error to be an alias for Box<Error>.

This was because:

• We wanted middleware to be as generic as possible, while requiring as few type parameters as possible. The hope that this would encourage users to create and share re-usable middleware, without having to specify an error type everywhere.
• It wasn't clear what downstream middleware/servers could do with the information in an error type. If a handler returns an error type, it's unlikely that the application could do much more than return a generic HTTP 500.

Since making this decision, we added the handler::static_files handlers, which attempt to catch io::Error and display a HTTP 404. These currently downcast the Box<Error>, which feels a little gross. Is there a better way?

Would aitch be more powerful if it somehow allowed users to specify a custom error type? What would that API look like?

Feedback very welcome!

Should the aitch crate be split out into separate crates?

The aitch crate was originally meant to define just the types necessary to create handlers/middlewares/bodies. The server backends and other middlewares were going to be defined in separate crates.

For ease of development, the other features were added to the main aitch crate, behind default-on optional cargo features. Should they be split out into separate crates? It would keep the main aitch crate small (as was intended), but make it more difficult for end-users to use.

The crate could be split by:

• aitch_hyper: Hyper back-end.
• aitch_tiny_http: tiny_http back-end
• aitch_json: Serde support
• aitch_static_files: Static file serving. (Although this might give the impression that it's production ready).
• aitch_simple_router: SimpleRouter, although maybe there should be a better aitch_router crate.

Should there be a generic Server trait?

We currently have implementations for two back-ends: Hyper and HTTP. Both expose a Server struct with a common interface.

So far they do not share a trait, but perhaps they should? Would this limit us from supporting other back-ends in the future, if they're unable to implement the trait for whatever reason? (Maybe they can't get the local addr they're bound to).

Would applications ever want to be generic over the server back-end used? That would be the biggest motivating factor for adding a trait.

Add static file(s) handler

Add tiny_http server

Create a production ready request Router

The crate provides SimpleRouter, which is primarily an example of how one might build a router or other complex middleware.

We should also provide (possible in a separate crate), a more production ready router, with features like:

• matching request method
• more complex path matching
• passing parameters from path into handler functions