Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OptionalPath extractor #1884

Closed
1 task done
jplatte opened this issue Mar 24, 2023 · 6 comments · Fixed by #1889
Closed
1 task done

OptionalPath extractor #1884

jplatte opened this issue Mar 24, 2023 · 6 comments · Fixed by #1889
Labels
A-axum-extra C-feature-request Category: A feature request, i.e: not implemented / a PR.

Comments

@jplatte
Copy link
Member

jplatte commented Mar 24, 2023

  • I have looked for existing issues (including closed) about this

Feature Request

Motivation

We've been getting many people asking about an easy way of extracting a path segment value only if a placeholder exists at the route the handler was called from.

Proposal

Add an extractor struct OptionalPath<T>(Option<T>); that succeeds with None if there are no placeholders for the given route, and if there are placeholders, attempts to deserialize the arguments to T and return Some(T) on success, rejecting the request on failure.

Alternatives

🤷🏼

@jplatte jplatte added C-feature-request Category: A feature request, i.e: not implemented / a PR. E-easy Call for participation: Experience needed to fix: Easy / not much A-axum-extra labels Mar 24, 2023
@simbleau
Copy link

            .route("/", get(handler)
            .route("/:path", get(handler))
pub(crate) async fn handler(
    path: Option<Path<String>>,
) -> impl IntoResponse
{
..
}

@jplatte
Copy link
Member Author

jplatte commented Mar 27, 2023

Yes, that works most of the time, but it doesn't reject the request for /:path requests with invalid UTF-8. Or maybe it does for the wrong reason. Anyways if using u32 instead of String in your example, a non-integer value for :path will still call the handler.

@davidpdrsn wdyt about this idea?

@davidpdrsn
Copy link
Member

I'm wondering if we can change PathRejection so you can tell if a param was missing, without needing a new extractor. An OptionalPath might still be worth it but in that case we could put it in axum-extra as a simple wrapper around Path + PathRejection::MissingParam (or smth)

@jplatte
Copy link
Member Author

jplatte commented Mar 27, 2023

Yeah, the idea was to put it in axum-extra, and implement it in terms of Path. I didn't realize that isn't yet possible 😄

@davidpdrsn
Copy link
Member

Then I think it's a good idea!

I don't specifically remember if its possible today but looking at PathRejection seems like we're missing a variant for it:

pub enum PathRejection {
    FailedToDeserializePathParams(FailedToDeserializePathParams),
    MissingPathParams(MissingPathParams),
}

MissingPathParams is for the internal extension missing and responds with Internal Server Error so that's a different thing. Though the name is a bit confusing in this context.

@jplatte jplatte removed the E-easy Call for participation: Experience needed to fix: Easy / not much label Mar 27, 2023
@davidpdrsn
Copy link
Member

Looking at PathRejection a bit more closely it seems we might be able to use WrongNumberOfParameters from the axum::extract::path::ErrorKind that you get from FailedToDeserializePathParams::into_kind.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-axum-extra C-feature-request Category: A feature request, i.e: not implemented / a PR.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants