Support chaining handlers with one.or(two).or(three)

[davidpdrsn]

This is something I've playing around with which I think we should explore in axum-extra. It enables doing handler fallbacks like this:

async fn one(Path(id): Path<u32>) -> String {
    id.to_string()
}

async fn two(Query(params): Query<Params>) -> String {
    params.a
}

async fn three() -> &'static str {
    "fallback"
}

let handler = one.or(two).or(three);
let app = Router::new().route("/:id", get(handler));

So if one rejects then two runs and finally three.

This is something users have asked about for but our current best solution is "do it manually in a single handler". That is quite tedious especially if you want to run different extractors for each handler.

[jplatte]

An interesting experiment, but I feel like to be robust, this would have to consider some extractors rejecting the request as fatal, while others trigger the .or fallback. That is, I would in most cases only want fallback for Path mismatches, not Query and certainly not extractors like Extension that are often not at all related to user input.

Also I'm having somewhat of a hard time reviewing the code. Docs are looking good though.

[takkuumi]

if there is a fallback, when to trigger fallback? all of them rejected?

[davidpdrsn]

if there is a fallback, when to trigger fallback? all of them rejected?

If an extractor rejects the fallback is called.

Cannot call the handler if the extractor doesn't succeed because we don't have a value of the right type. So we must call the next handler in the or chain.

[jplatte]

Hm, maybe we should also have Either<A, B> .. Either8<A, B, C, D, E, F, G, H> extractors in axum-extra as a more fine-grained fallback thing? Those should be easier to use than separate Option extractors where you handle all of them failing manually. (although not as convenient as this PR if you really want entirely separate handler logic)